PPP协议原理介绍+报文分析+配置指导-RFC1661

个人认为，理解报文就理解了协议。通过报文中的字段可以理解协议在交互过程中相关传递的信息，更加便于理解协议。

因此本文将在PPP协议报文的基础上进行介绍。

• 关于PPP协议基本原理，可参考RFC1661-The Point-to-Point Protocol (PPP)。

• 关于PPP协议的IPv4控制协议，可参考RFC1332-The PPP Internet Protocol Control Protocol (IPCP)。
• 关于PPP协议的压缩控制协议，可参考RFC1962-The PPP Compression Control Protocol (CCP)。
• 关于PPP协议的挑战握手认证协议，可参考RFC1994-PPP Challenge Handshake Authentication Protocol (CHAP)。
• 关于PPP协议的报头压缩协议，可参考RFC3241-Robust Header Compression (ROHC) over PPP。
• 关于PPP协议的IPv6控制协议，可参考RFC5072-IP Version 6 over PPP。
• 关于PPP协议的相关参数，可参考IANA的Point-to-Point (PPP) Protocol Field Assignments。
• 关于PPP协议的其他资料，可参考博客【网络协议详解】——PPP协议（学习笔记）。
  …

PPP协议还存在大量相关RFC，感兴趣者可查阅相关资料。

PPP（The Point-to-Point Protocol，点到点协议）提供了一个在点对点链路上传输多种协议数据包方法的协议标准。
个人能力有限，这里仅涉及简易内容。敬请各位指导。

目录

1.基础介绍

1.1.PPP协议背景

PPP（The Point-to-Point Protocol，点到点协议）主要是为在点对点链路上传输多种协议数据包提供了一个标准方法的协议。

在上世纪 80/90 年代，Internet 上支持 TCP/IP 的主机数量呈爆炸式增长。这些主机中的绝大多数以 Ethernet 为代表连接到局域网（LAN），或以 X.25 协议等方式连接广域网（WAN）。 点对点链路作为最古老的数据通信方法之一，尽管当时几乎每台主机都支持点对点连接，却鲜有以简单的点对点链路连接。

点对点 IP 链路数量较少的一个原因是缺乏公认的标准封装协议。因此 Internet Engineering Task Force (IETF) 工作组于1989年 发布 RFC1134 定义了 PPP 协议，以便在 PPP 链路上支持传输多种协议类型。PPP 协议经多年的发展，目前广为接受的标准为 RFC1661-The Point-to-Point Protocol (PPP)。

RFC1661 中标准化的 PPP 协议主要定义了三部分内容：

1. 如何封装多种协议数据包，例如 IPv4/IPv6、OSI Network、Novell IPX 等；
2. 如何通过 LCP 协议（Link Control Protocol，链路控制协议）建立、配置和测试数据链路层的连通性；
3. 如何通过 NCP 协议（Network Control Protocols，网络控制协议）建立和配置不同网络层的协议。

PPP协议的基本工作过程为：

• 首先发送 LCP 包以便进行数据链路的配置和测试。
• 在数据链路的 Establish 和可选参数协商完成后，发送 NCP 包进行网络层协议的配置和协商。
• PPP 链路持续交互直到发送出 LCP/NCP 关闭链路，或者定时器超时等额外事件的发生。

如果启用了认证等相关功能，则会在 LCP 阶段协商完成后进行认证过程的协商。

1.2.相关术语及概念

Encapsulation：PPP Encapsulation 用于在同一个 PPP 链路上承载多种网络协议。当使用 HDLC-like 封装时，仅需添加 8 字节的 PPP Header。而在带宽比较宝贵的场景下，以 2 或 4 字节的 PPP Header 封装数据。

//上图即为承载 IP 协议时的 PPP 报文，其 PPP Header 长 4 字节。

Link Control Protocol：LCP 链路控制协议，是 Link-layer Control Protocols 的一种。LCP 可用于协商封装格式选项和包尺寸大小，探测链路环回和参数错配，终止链路。

LCP 链路控制协议，是 Link-layer Control Protocols 协议最常用的一种。PPP 协议可承载的其他 Link-layer Control Protocols 协议有 PAP (Password Authentication Protocol，密码认证协议；Protocol Number = 0xc023) 和 CHAP (Challenge Handshake Authentication Protocol，挑战握手认证协议；Protocol Number = 0xc223) 等。

Network Control Protocols：NCP 网络控制协议，是一系列网络层协议的总称。PPP 协议利用 NCP 协议完成所运行网络协议的协商。常用的 NCP 协议有 IPCP（IP Control Protocol）、IPv6CP（IPv6 Control Protocol）和 MPLSCP（MPLS Control Protocol）等。

在之前的 PPP 协议报文示例中，可以注意到 PPP Header 中存在一个 2 字节的 Protocol 字段用于表示 PPP 所承载的协议类型。IETF (Internet Engineering Task Force，国际工程任务组) 在 RFC1661 中大致将 LCP、NCP 以及 NLP (Network Layer Protocols) 等协议的 Protocol Numbers 进行了如下划分：
以上几类协议可以大致这样理解：控制协议用于 PPP 建立交互的协商协议，网络层协议用于 PPP 实际承载业务报文。
例如，当 PPP 的 Protocol Number 为 0x8021 时表示 IPCP 可用于协商 IPv4 网络的相关参数；当为 0x0021 时表示 IPv4 可用于承载具体的 IP 协议报文，例如 ICMP 和 TCP 等。相似的有 0x8281 时表示 MPLSCP 用于协商 MPLS 网络的相关参数；0x0281 时表示承载具体 MPLS 单播业务报文。
自动换行//也即有上述图示的逻辑结果。

PPPoE：Point-to-Point Protocol over Ethernet，PPP协议封装于以太网上的协议。PPPoE协议定义于 RFC2516-A Method for Transmitting PPP Over Ethernet (PPPoE)。其基本格式为在 PPP 协议基础上封装 PPPoE Header 后作为 Ethernet 帧 Payload 的形式存在。

此处不在对 PPPoE协议做更多介绍，感兴趣者可查阅相关资料。

2.PPP协议原理

//根据前文描述，PPP 协议的基本工作过程如上图所示。这里依次进行相应原理介绍。

点击此处回到目录

2.1.PPP协议帧格式

2.1.1.LCP帧格式

RFC1661 中定义的 LCP 包格式

通用的 LCP 包格式：Code：代码，1字节。用于标识 LCP 包类型。当收到未知类型的 LCP 包时，应当回应 Code = 7 的 Code-Reject 帧。

目前 RFC 标准化了14种 LCP 包：//其中 8-13 是 LCP 协议独有的 code 类型。这里暗含的意思是 LCP 协议和 IPCP 协议具有相同的帧格式，共用部分 code 码。

Identifier：身份标识，1字节。主要用于匹配 Request 类型和 Reply 类型的消息。

由于 PPP 链路建链协商时不携带 MAC 或 Router-id 等用于标识的链路节点的信息，需要通过该字段进行相互识别。
每当设备启动发送 LCP 报文时从 0x00 开始计数，每发送一次 LCP 包 Identifier 序号加一直至 0xff。随后从 0x00 开始下一轮循环。
通常仅允许 Request 类型包在重传时不改变 Identifier 序号。Reply 类型包应当与 Request 类型的 Identifier 序号一致。

Length：长度，2字节。标识整个 LCP 包的长度，并且标识长度不应超过链路的 MRU (Maximum-Receive-Unit，最大接受单元)。对于超过 Length 标识的部分应当在接受时忽略。如果接收到不可用的 Length 字段，应当静默丢弃。
Data：数据，长度取决于 Length 标识值。 Data 字段的内容还受到具体 LCP 包的影响。

//上图为一个典型的 LCP 包图示，后文将针对交互过程对其进行介绍。

1@=Configure LCP 包格式：RFC1661
Configure LCP 包的 Code：共有4种类型。主要用于链路节点协商连接请求。

1. Code = 1 表示 Configure-Request LCP 包。每当期望建立某种连接时，携带相应的 LCP Option 发起 Code = 1 的Configure-Request LCP 包开启交互请求。
2. Code = 2 表示 Configure-Ack LCP 包。当收到的 Configure-Request LCP 包每个 Option 可识别且接受时必须回应 Configure-Ack LCP 包，并且携带未经重新排序和修改的 Option。
3. Code = 3 表示 Configure-Nak LCP 包。当收到的 Configure-Request LCP 包每个 Option 可识别但部分 Option 的值不可接受时必须回应 Configure-Nak LCP 包，并且携带未经重新排序的不可接受 Option。

除此之外还要求：
1@：没有 Value 字段的选项 Option 必须改用 Code = 4 的 Configure-Reject LCP 包回复。
2@：每个只允许出现一次的 Option 必须修改为 Configure-Nak 发送方可接受的值。当默认值与请求的值不同时，可以使用默认值。
3@：当特定类型的 Option 出现多次并具有不同的值时，Configure-Nak 必须同样出现多次并包含该 Option 的所有值，这些值是 Configure-Nak 发送方可接受的。 这包括 Configure-Request 中存在的可接受值。
4@：当需要某种协商需求而 Configure-Request LCP 包未列出该 Option ，则可以将该 Option 附加到 Configure-Nak 的 Option 中，以提示对等方将该 Option 包含在其下一个 Configure-Request LCP 包中。 Option 的 Value 应当是 Configure-Nak 发送方可接受的值。在接收 Configure-Nak 包时，Identifier 字段必须与上次传输的 Configure-Request LCP 包匹配。 无效数据包将被静默丢弃。
对端收到有效的 Configure-Nak LCP 包而在发送新的 Configure-Request LCP 包时，可以按照 Configure-Nak 包中的指示修改 Option。当存在 Option 的多个实例时，对等方应选择一个值以包含在其下一个 Configure-Request 包数据包中。某些 Option 具有可变长度。由于 Nak’d Option 已被 Configure-Nak 包发送方修改，因此重新发送 Configure-Request LCP 包的一方必须具有能够处理与原始 Configure-Request 不同的 Option 长度的能力。

4. Code = 4 表示 Configure-Reject LCP 包。当收到的 Configure-Request LCP 包中某些 Option 无法识别或无法协商（由网络管理员配置），则实现必须回应Configure-Reject LCP 包。 Option 字段仅填充 Configure-Request LCP 包中不可接受的 Option，并且不得以任何方式重新排序或修改配置选项。收到 Configure-Reject LCP 包的一方在发送新的 Configure-Request LCP 包时，它不得包含 Configure-Reject 包中列出的任何 Option。

Configure-Nak LCP 包和 Configure-Reject LCP 包区别在于：Configure-Nak LCP 包表示双方可以重新协商需求值，而 Configure-Reject LCP 包表示双方明确不可针对某一需求进行交互。

这一过程往往发生在 LCP 已经完成了链路发现，需要进一步进行 NCP 交互时事先确认的某些信息或者管理者更改了网络层信息。

//例如此处携带的即为认证 Option，LCP Option 携带 CHAP 协议进行认证。

2@=Terminate LCP 包格式：RFC1661
Terminate LCP 包的 Code：共有2种类型。Terminate LCP 包主要用于关闭连接。

1. Code = 5 表示 Terminate-Request LCP 包。当链路节点希望关闭连接时，应当持续发送 Terminate-Request LCP 包直到收到 Terminate-Ack LCP 包。而未经 Request 而收到 Terminate-Ack LCP 包时，通常也意味着对等体处于 Closed/Stopped 状态，或者需要重新协商。
2. Code = 6 表示 Terminate-Ack LCP 包。当收到 Terminate-Request LCP 包时，必须发送 Terminate-Ack LCP 包。

3@=Code-Reject LCP 包格式：RFC1661
Code-Reject LCP 包的 Code：共有1种类型。Code-Reject LCP 包主要用于响应未知 Code 的 LCP 包。

1. Code = 7 表示 Code-Reject LCP 包。当链路节点处于 Open 状态收到对等体发送来的未知类型的 LCP 包时，应当发送 Code-Reject LCP 包。Code-Reject 数据包只能在 LCP Opened 状态下发送。Reject-Packet 字段应当不包含数据链路层头部或 FCS，并可因 MRU 限制而截断。
   在 LCP 打开状态以外的任何状态下接收的协议拒绝数据包都应以静默方式丢弃。在收到 Code-Reject 后，对等体必须尽早停止发送该未知类型的 LCP 包。

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

Protocol-Reject LCP 包的 Code：共有1种类型。Protocol-Reject LCP 包主要用于响应未知或未使能的 Protocol 的 LCP 包。

1. Code = 8 表示 Protocol-Reject LCP 包。当链路节点处于 Open 状态收到对等体发送来的未知类型的 LCP 包时，应当发送 Protocol-Reject LCP 包。Protocol-Reject 数据包只能在 LCP Opened 状态下发送。在 LCP 打开状态以外的任何状态下接收的协议拒绝数据包都应以静默方式丢弃。Reject-Information 字段应当不包含数据链路层头部或 FCS，并可因 MRU 限制而截断。
   在 LCP 打开状态以外的任何状态下接收的协议拒绝数据包都应以静默方式丢弃。在收到 Protocol-Reject 后，对等体必须尽早停止发送该未知类型的 LCP 包。

//这是由于未使能 MPLS 而导致对 MPLSCP 协议回应的 LCP Protocol Reject 包。

5@=Echo LCP 包格式：RFC1661
Echo LCP 包的 Code：共有2种类型。Echo LCP 包主要用于调试、链路质量确定、性能测试等其他方面。

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

1@：Echo-Request 和 Echo-Reply LCP 包只能在 LCP Opened 状态下发送。
2@：在收到 Echo-Request 时，必须发送 Echo-Reply。在 LCP Opened 状态以外的任何状态下收到的 Echo-Request 和 Echo-Reply 数据包都应以静默方式丢弃。
3@：Magic-Number 的使用与 Magic-Number Option相关。在成功协商 Magic-Number Option 之前，必须以零形式传输。
3@：Data 字段是可为0的任意值，并受 Length 字段的控制。
//这里的 Data 为 0 的 Echo LCP 包示例。

6@=Discard-Request LCP 包格式：RFC1661
Discard-Request LCP 包的 Code：共有1种类型。Discard-Request LCP 包主要用于提供数据链路层接收器机制，用于执行链路的本地到远程方向。

1. Code = 11 表示 Echo-Request LCP 包。Discard-Request 数据包只能在 LCP Opened 状态下发送。在接收时，接收方必须静默地丢弃它收到的任何丢弃请求。

7@=Identification LCP 包格式：RFC1570
Identification LCP 包的 Code：共有1种类型。Discard-Request LCP 包提供了一种用于向对等体标识自己的方法。可用于链接故障排除、执行许可证等。

1. Code = 12 表示 Identification LCP 包。Identification LCP 包可以随时发送，包括在 LCP 达到 Open 状态之前。收到标识数据包会导致 RXR 或 RUC 事件。Identification LCP 包生成情况既罕见又单向，建议在发送或接收 Configure-Reject 时发送。或者，在协商无法收敛时以及 LCP 达到 Opened 状态时作为最终消息发送。
   Message 字段往往包含：硬件类型、PPP 软件修订版本、PPP 产品序列号、链路速率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 包是一个链路维护数据包。 剩余时间数据包只能在 LCP Open 状态下发送。收到剩余时间数据包会导致 RXR 或 RUC 事件，并无需对 Time-Remaining LCP 包进行响应。

点击此处回到目录

2.1.2.LCP Configuration Options

IANA目前定义了约30种 LCP Configuration Options，这里仅介绍常用的几种 Options。其他 Options 感兴趣者可查阅相关资料。

1@：LCP Configuration Options 主要用于提供链路节点双方一种协商默认参数的方法。
2@：某些 Options 可能出现不仅一次。
3@：Option 通常出现在 Code = 1 的 Configure-Request LCP 包中。

通用的 LCP Configuration Options 格式：
Type 字段用于标识 Option 类型，Length 字段用于描述整个 Option 的长度，Data 字段则为 0 至 Length-2 的值。

Type 1 = Maximum-Receive-Unit Options：RFC1661
Maximum-Receive-Unit Option 用于标识自己所能接受的最大字节数，默认取值 1500。但是链路节点应当至少支持接受 1500 字节的能力。

//配置 PPP 链路的MRU协商功能。默认使能，取值取决于链路上 MTU 的设置。

Type 3 = Authentication-Protocol Options：RFC1661/RFC1994
Authentication-Protocol Option 用于指示在进行 NCP 交互前的认证信息确认。但是一个 Configure-Request LCP 包中不能出现多个 Authentication-Protocol Option ，只能在接受 Configure NAK 之后发起下次 Configure-Request。

//这里展示的即为协商 CHAP 的 Authentication-Protocol Options。其中定义的 Algorithm认证算法 = 5 表示 CHAP with MD5。其他认证算法可查阅相关资料。
自动换行
还有一个需要注意的是：RFC1661 认为 PPP 的认证并非一个全双工过程。也即，允许单方向发起认证请求而认证方仅进行认证确认即可。
被认证方需配置：
//ppp pap local-user 用于携带认证的用户名和密码向对端请求进行认证。当然也可选择 CHAP 认证的方式。
认证确认方需配置：
//ppp authentication-mode 用于设置认证模式。
//local-user 用于设置进行 PPP 认证所需的用户名和密码。

Type 4 = Quality-Protocol Options：RFC1661
Quality-Protocol Option 用于使用特定协议进行链路质量监控。默认情况下，链路质量监控处于禁用状态。

Type 5 = Magic-Number Options：RFC1661
Magic-Number 用于检测环回链路和其他数据链路层异常。默认情况下，不会协商 Magic-Number，而是在可能使用幻数的地方插入零。Magic-Number 的产生通常是使用随机的方式生成。当收到带有 Magic-Number Option 的 Configure-Request LCP 包时，收到的 Magic-Number 将与最后一个发送给对等体的 Configure-Request LCP 包中 Magic-Number 进行比较：
如果两个 Magic-Number 不同，则链接不会环回，并且应确认幻数。
如果两个 Magic-Number 相等，则链路可能（但不确定）是环回的。要确定这一点，必须发送指定不同 Magic-Number 的 Configure-Nak LCP 包，直到收到 Configure-Nak 或重新启动计时器用完之前，不应将新的 Configure-Request LCP 包发送到对等体。当然后续收到的 LCP 包中的 Magic-Number 仍然有可能相等，尽管这种概率非常小。因此RFC1661建议应当尽可能的设置多的 Magic-Number 来源，或者不启用这一功能。

//此处携带一个随机产生的 Magic-Number Option 用于检测链路是否环路。
//一旦协商完成后，在周期性发送的 Echo Request 和 Echo Reply LCP 包中一直携带该字段直到重新协商。似乎，某种程度上可用于链路节点的标识。

Type 6 = Protocol-Field-Compression Options：RFC1661
Protocol-Field-Compression 用于协商对2字节 PPP Protocol 字段的压缩。

Type 7 = Address-and-Control-Field-Compression：RFC1661
Address-and-Control-Field-Compression 用于协商对 Data Link Layer Address and Control 字段的压缩。

2.1.3.IPCP帧格式及其Option-RFC1332

IPCP协议，也即 IP Control Protocol 协议作为 NCP 协议的一部分，主要用于在 PPP 链路上配置、使能和去使能 IPv4 协议模块。关于 IPv6 网络下的 IPv6CP 协议可参考RFC5072-IP Version 6 over PPP

IPCP协议有如下几个特点：
1@：IPCP 协议交互基本原理与 LCP 协议基本相同。并在 PPP 链路协议状态达到 Network-Layer Protocol 阶段开始交互，在此之前接受到的 IPCP 包应当静默丢弃。
2@：IPCP 协议与 LCP 协议不同之处在于 Data Link Layer 的 Protocol 字段取值为 0x8021。
3@：IPCP 协议与 LCP 协议不同之处在于 Code 字段只能使用 LCP 协议的 1-7 种类型。其他类型的 Code 字段应当被视为未知 Code，并且应当回应 Code-Rejects 包。
4@：IPCP 协议与 LCP 协议不同之处在于 IPCP 协议仅在 PPP 链路协议状态达到 Network-Layer Protocol 阶段开始交互。在等待 Configure-Ack 或其他响应超时之前，应准备好等待身份验证和链路质量确定完成。
5@：IPCP 协议与 LCP 协议不同之处在于 IPCP 协议具有不同的 Configuration Option Types。

IPCP协议帧格式示例：
这里展示了初始状态下携带的三种 IPCP Configuration Option Types：
1@：Type3 = IP address，定义于RFC1332。用于协商 PPP 链路节点的 IP address。这一描述主要包含了两种行为：首先可用于链路节点间 IP 地址的冲突检测，此外还可用于向节点对等体请求为自己分配一个地址。

这里 IP address 填充 0.0.0.0 即表示用于向对端请求为自己分配一个地址。此时链路对等体返回 Configure-Nak IPCP 包并填充分配的地址，随后链路节点以该值继续发起 IPCP 包再次进行请求。通过这种拒绝再次请求的方式完成 IP 地址的分配工作。详细的交互过程将在第三章进行相应介绍。

2@：Type129 = Primary DNS Server Address，定义于RFC1877。用于协商 PPP 链路节点的 Primary DNS Server Address。
3@：Type131 = Secondary DNS Server Address，定义于RFC1877。用于协商 PPP 链路节点的 Secondary DNS Server Address。

与 Type3 = IP address Option 类似，Type129 = Primary DNS Server Address 和 Type131 = Secondary DNS Server Address 具有类型的两种行为。也即协商 DNS，或向对端请求 DNS。并在请求 DNS 时将相应字段置位 0.0.0.0。

除此之外，IANA 还定义了其他几种 IPCP Configuration Option：
Type129 = Primary NBNS Server Address 和 Type131 = Secondary NBNS Server Address 定义于 RFC1877 中，主要用于协商 NetBIOS Name Server 地址。NetBIOS 协议主要为程序提供了请求低级服务的统一的命令集 (或者提供应用程序编程接口（API）)，作用是为了给局域网提供网络以及其他特殊功能
Type2 = IP-Compression-Protocol 定义于 RFC1332 中，主要用于协商如何压缩 TCP/IP 头部以便在低带宽条件下提升载荷效率。//其通用格式如上图所示。目前所常用的 IP-Compression-Protocol 有：
Van Jacobson Compressed TCP/IP (Value = 0x002d，RFC1332)：
//ip tcp vjcompress 命令用来配置PPP链路接口的VJHC压缩功能。通过VJHC压缩后，TCP/IP头长度可以从40字节降至3～5字节，在PPP链路上可以明显提高报文的传输速度。
Robust Header Compression (ROHC) (Value = 0x0003，RFC3241)、
IP Header Compression (Value = 0x0061，RFC2507和RFC3544)//ppp compression iphc 用来配置PPP链路接口上IPHC功能。
VJHC和IPHC的区别是：VJHC仅仅对TCP/IP报文头进行压缩；IPHC可以对TCP/IP报文头或RTP/UDP/IP报文头进行压缩。其他 IP-Compression-Protocol 及 IPv6-Compression-Protocol 不在进行相关介绍，感兴趣者可查阅相关资料。

点击此处回到目录

2.2.PPP协议基本原理

2.2.1.PPP相图/Phase Diagram

在RFC1661 中定义了 PPP 链路的配置、维护和终止阶段，主要可分为上图所示的几个相。

Link Dead：PPP 链路的开始和结束阶段。在此阶段 LCP 状态机处于 Initial/Starting 初始/启动中状态。

当有额外的 Event 事件发生时 (例如，载波监听或网络管理配置)，预示着物理层可用并准备进入 Establishment 阶段。

Link Establishment：在此阶段，LCP 通过交互配置消息来建立连接。一旦发送和接收了 LCP Configure-Ack 包，交互即宣告完成并进入 LCP 的 Open 状态。

在此阶段接收的任何非 LCP 数据包都必须以静默方式丢弃。收到 LCP 配置请求会导致从 Network 阶段或 Authentication 阶段返回到 Link Establishment 阶段。

Authentication：默认情况下，身份验证不是强制性的。如果需要认证，则建立链接后，应尽快进行身份验证。

在身份验证完成之前，不得从身份验证阶段推进到 Network-Layer 协议阶段。 如果身份验证失败，身份验证器应改为进入 Link Termination 阶段。在此阶段，只允许使用 LCP、认证协议和链路质量监控。收到的所有其他数据包必须静默丢弃。

Network-Layer：PPP 完成上述阶段后，必须由相应的 NCP 单独配置每个网络层协议。

当相应的 NCP 未处于 Open 状态时，必须以静默方式丢弃任何受支持的网络层协议数据包。当 LCP 处于 Opened 状态时，实现不支持的任何协议数据包都必须返回 Protocol- Reject 包。只有受支持的协议才会被静默丢弃。

Link Termination：LCP 用于通过交换 Terminate 数据包来关闭链路。

Terminate-Request 的发送方应在收到 Terminate-Ack 后或 Restart 定时器过期后断开连接。Terminate-Request 的接收方应在发送 Terminate-Ack 后至少经过一个重启时间之前不得断开连接。

2.2.2.PPP状态机

PPP 协议有限状态机由 Event事件、Action动作 和 state transitions状态切换 共三部分组成。

Event事件 通常是指发生了某一现象或某一行为；Action动作 是指针对 Event事件 所作出的响应；state transitions状态切换 是指将PPP链路状态发生某种转变。
这里仅针对部分内容进行说明，详细内容可查看相关资料。

RFC1661 定义了如上图所示的 Event事件 和对应的 Action动作：

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

RFC1661 定义了一个名为 Restart Timer 的定时器，默认取值 3s。当链路节点发出 LCP Configure-Request/Terminate-Request 等请求类型的 LCP 包，启动该定时器。如果定时器结束而未收到响应，则触发 Restart TimerTime Out Event。同时该值的设置也应当考虑链路延时及设备处理所耗费时间的额外设置。
//ppp timer negotiate 用来配置PPP协商超时时间间隔，默认取值 3s。
自动换行
RFC1661 定义了一个名为 Max-Configure 的计数器，默认取值 10。该计数器用于指示在发出 LCP Configure-Request 包后未收到对方响应的最大次数。
也即，发出 10 次 LCP Configure-Request 包而未收到响应将触发 Event = TO-。1 - 9 次则触发 Event = TO+。

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

RCR Event 用于分别表示链路节点收到 Configure-Request LCP 包动作。随后针对该事件回应 Configure-Ack/Configure-Nak/Configure-Reject LCP 包。

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

RTR/RTA Event 通常发生于因某些状况导致需要中断 PPP 连接的情况。在该情况下，RFC1661 还定义了名为 Max-Terminate 的计数器，默认取值 2。用于表示发出 Terminate-Request 而未收到 Terminate-Ack 的最大次数。

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

当收到 Echo-Request, Echo-Reply, Discard-Request LCP 包时触发该事件。对 Echo-Request 回应 Echo-Reply。其他情况无回应。
//ppp keepalive retry-times 用来配置PPP心跳报文的重传次数。当链路质量差，发送的心跳报文达到重传次数时，设备会断开PPP连接。

同时，RFC1661 还定义了如上图所示的 10 种 state 状态：
水平指示 State，垂直指示 Event，State Transitions 以 action/new-state 形式表示。
多个操作用逗号分隔，并可根据空间需要在后续行上继续执行。可以以任何方便的顺序实现多个操作。
状态后面的字母，表示一个解释性脚注。
短划线 （‘-’） 表示非法转换。

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

State = Closed：链接可用，但 Open 未发生。 执行 irc = Initialize-Restart-Count 和 scr = Send-Configure-Request 可过渡到 State = Req-Sent。
State = Stopped：当自动机在 This-Layer-Finished 操作之后或发送 Terminate-Ack 后等待 Down 事件时进入。
State = Request-Sent：此状态，链路节点试图配置联系。
State = Opened：Configure-Ack LCP 包已经完成收发。Restart 定时器不在运行。处于此阶段需要向上层协议通告 UP。

点击此处回到目录

3.PPP协议常用配置及报文交互实例

//根据前文描述，PPP 协议的基本工作过程如上图所示。这里依次进行相应介绍。

3.1.PPP协议常用场景及配置

这里以下图为例进行PPP协议交互场景的配置介绍及其对应的报文分析。
在上图场景中：AR1 做 AR2 的PPP认证方，并为 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报文交互过程

报文交互以 LCP – PAP – NCP 的顺序先后进行。
其报文总体交互过程如上图所示，此处以上图报文顺序先后进行介绍。
No.1为废弃报文此处不做介绍。

No.2 和 No.3：
这是第一次 PPP 链路节点双方进行的第一次配置确认。在该阶段相互确认链路层所需信息。

//由于 AR2 配置了认证，所以可观察到其发出的 Authentication Option。

No.6 和 No.7：
在节点双方都进行了一次 Configure 确认后进入认证阶段。

//PAP 认证以明文方式进行信息交互。相关 Option 可查看前文介绍。

No.8 至 No.13：
该阶段也即 NCP 阶段进行 IP 协议的协商。

//由于一方请求了IP及DNS，所以相应字段至0。并会被 AR1 拒绝并携带正确的值。AR2 收到后，再次携带正确 Option 向 AR1 发起请求。至此双方都完成 IP 层协商。
这里还需要注意的一个点是：PPP 链路不进行类似 Ethernet 协议的子网验证，因此实际上可以出现对端 IP 跨网段的现象。并默认将 PPP 链路对等体的 32 位主机路由加入本地路由表。

No.14 至 No.17：
此后完成 LCP 和 NCP 阶段的协商，周期性每 10s 进行一次PPP交互确认。

//这里开始交互 Echo 消息，并携带相应的 Magic Number。
相关内容可查看前文介绍。

Terminate LCP 报文交互类型与上述交互过程类似，此处不在进行相关介绍。
MPLSCP 协议作为 NCP 协议的一种与上述交互过程类似，此处不在进行相关介绍。

更新

点击此处回到目录