课程 BA000003
PPP协议和PPP0E协议
Huawei Technologies
目 录
课程说明 .....................................................................................................................................................1
课程介绍 .....................................................................................................................................................1
课程目标 .....................................................................................................................................................1
第 1 章 概述 ................................................................................................................................................2
第 2 章 PPP 协议.........................................................................................................................................8
第 3 章 PPPOE 协议 .................................................................................................................................48
附录 缩略词表 .........................................................................................................................................74
课程说明
课程介绍
本教材为宽带产品工程师培训公共课程。
本课程介绍 PPP 协议和 PPPOE 协议。
课程目标
完成本课程学习，学员能够：
了解 SLIP 协议的基本原理。
掌握 PPP 协议的基本原理。
掌握 LCP 协议和 NCP 协议数据报文的交换过程。
掌握 PPPOE 协议的基本原理。
第1章 概述
PPPOE协议
PPP协议
SLIP协议
内容提要
SLIP 的全称是 Serial Line IP，出现在 80 年代中期，并被使用在 BSD UNIX 主
机和 SUN 的工作站上。因为 SLIP 简单好用，所以后来被大量使用在线路速率
从 1200bps 到 的专用线路和拨号线路上互连主机和路由器，到目前
为止仍有大部分 UNIX 主机保留对该协议的支持。在 80 年代末 90 年代初期，
被广泛用于家庭中每台有 RS232 串口的计算机和调制解调器连接到 Internet。
SLIP 的帧格式由 IP 包加上 END 字符组成。
通过在被发送 IP 数据报的尾部增加特殊的 END 字符（0xC0 ）从而形成一个
简单的 SLIP 的数据帧，而后该帧会被传送到物理层进行发送。为了防止线路
噪声被当成数据报的内容在线路上传输，通常发送端在被传送数据报的开始
处也传一个 END 字符。如果线路上的确存在噪声，则该数据报起始位置的
END 字符将结束这份错误的报文，这样当前正确的数据报文就能正确的传送
了，而前一个含有无意义报文的数据帧会在对端的高层被丢弃。
END 是判断一个 SLIP 帧是否结束的标志。如果要传送的 IP 包中正好有一个
字符 0xc0 要传送，为了避免它被当作 END 字符，要用连续的两个字节 0xdb
和 0xdc 来代替它。如果要传送的是 0xdb，那么就用连续传输两个字节 0xdb
和 0xdd 来代替它。
IP数据报文 + END字符 = SLIP数据帧
定义：
SLIP是在串行线路上对IP数据报进行封装的简单协议。
SLI P协议的定义
SLIP数据帧格式：
SLIP 只支持 IP 协议，对 IPX 等缺乏支持。并且，由于帧格式中没有类型字段，
致使如果一条串行线路如果用于 SLIP，就不能同时使用其它协议。
IP
IPX
AppleTalk
路由器A 路由器B
SLIP链路
IP
IPX
AppleTalk
SLI P协议的缺点（一）
SLIP 不提供纠错机制，错误只能依靠上层协议实现。
01010101111100011100
NoiseHello
01010101000100011100
Heolo
1 2 3
有误重传
4
路由器A 路由器B
SLI P协议的缺点（二）
SLIP 帧的封装格式非常简单，通信双方无需在数据报发送前协商任何配置参
数选项（在 PPP 协议中需协商配置参数选项），所以双方 IP 层通信前必需先
获知对方的 IP 地址，才能进行网络层的通信，否则链路层发送的数据帧在被
送到对方网络层时将无法进行转发。正是由于上面的诸多缺点，导致了 SLIP
很 快 的 被 后 面 要 讲 的 PPP 协 议 所 替 代 。
路由器A 路由器B
SLIP链路
路由器B的互连IP是多少？
打个电话问问
我的地址是
你的地址是多少？
还要通过这么原始的方式来获知对方的IP地址
SLI P协议的缺点（三）
小节
SLIP是一种仅能在点对点的链路上封装IP数据报的协议
SLIP的帧格式为 IP数据报 c0
SLIP不支持IP地址的协商
第2章 PPP 协议
PPPOE协议
PPP协议
SLIP协议
内容提要
PPP协议的定义：
PPP协议提供了一种标准的方式在点对点的链路上传输多种
网络层协议的数据报。
PPP协议与协议栈的对应关系
物理层
数据链路层
网络层
传输层
会话层
表示层
应用层
PPP协议
PPP协议简介
支持点到点的连接，不同于X. 25、f r ame r el ay等数据链
路层协议，具有CHAP、PAP验证协议，更好的保证了网络的安
全性。
PPP的物理层既支持数据为8位和无奇偶校验的异步模式，
还支持面向比特位的同步链接，如f r ame r el ay必须为同步电
路。
PPP有针对不同网络层的网络控制协议，如大家熟知的
I PCP, I PXCP。同样类似于SLI P协议，它也允许双方协商是否
对报文首部进行压缩。
PPP协议的特点
PPP 协议主要包括三部分：LCP（Link Control Protocol）链路控制协议、NCP
（Network Control Protocol）和 PPP 的扩展协议（如 Multilink Protocol）。随
着网络技术的不断发展，网络带宽已不再是瓶颈，所以 PPP 扩展协议的应用
也就越来越少，因此往往人们在叙述 PPP 协议时经常会忘记它的存在。
PPP协议的三组件
多协议数据报的封装方式
PPP协议的链路控制协议LCP
PPP协议的网络控制协议NCP
我们在提及 PPP 协议的报文封装格式时，不可不先提一下 HDLC 协议。HDLC
也是最常用的数据链路层协议，它是从 SDLC 协议衍进过来的，许多常用的
数据链路层协议的封装方式都是基于 HDLC 的封装格式的，同样 PPP 协议也
不例外，它也采用了 HDLC 的定界帧格式。
以下为对 PPP 数据帧封装格式的一点说明：
每一个 PPP 数据帧均是以一个标志字节起始和结束的，该字节为 0x7E。
紧接在起始标志字节后的一个字节是地址域，该字节为 0xFF。我们熟知网络
是分层的，且对等层之间进行相互通信，而下层为上层提供服务。当对等层
进行通信时首先需获知对方的地址，而对不同的网络，在数据链路层则表现
为需要知道对方的 MAC 地址、 地址、ATM 地址等；在网络层则表现为
需要知道对方的 IP 地址、IPX 地址等；而在传输层则需要知道对方的协议端
口号。例如如果两个以太网上的主机希望能够通信的话，首先发送端需获知
对端的 MAC 地址。但由于 PPP 协议是被运用在点对点的链路上的特殊性，它
不像广播或多点访问的网络一样，因为点对点的链路就可以唯一标示对方，
因此使用 PPP 协议互连的通信设备的两端无须知道对方的数据链路层地址，
所以该字节已无任何意义，按照协议的规定将该字节填充为全 1 的广播地址。
同地址域一样，PPP 数据帧的控制域也没有实际意义，按照协议的规定通信双
方将该字节的内容填充为 0x03。
校验标志 标志地址 信息域控制 协议域
1B 1B 2B缺省1500B
7E FF 03
1B 2B 1B
7E
PPP的数据帧格式
就 PPP 协议本身而言，我们最关心的内容应该是它的协议域和信息域。协议
域可用来区分 PPP 数据帧中信息域所承载的数据报文的内容。协议域的内容
必须依据 ISO 3309 的地址扩展机制所给出的规定。该机制规定协议域所填充
的内容必须为奇数，也即是要求低字节的最低位为“1”，高字节的最低位为
“0”。如果当发送端发送的 PPP 数据帧的协议域字段不符合上述规定，则接收
端 会 认 为 此 数 据 帧 是 不 可 识 别 的 ， 那 么 接 收 端 会 向 发 送 端 发 送 一 个
Protocol-Reject 报文，在该报文尾部将完整地填充被拒绝的报文。
信息域缺省时最大长度不能超过 1500 字节，其中包括填充域的内容，1500 字
节大小等于 PPP 协议中配置参数选项 MRU（Maximum Receive Unit）的缺省
值，在实际应用当中可根据实际需要进行信息域最大封装长度选项的协商。
信息域如果不足 1500 字节时可被填充，但不是必须的，如果填充则需通信双
方的两端能辨认出有用与无用的信息方可正常通信。
说明：
MRU 表示本端接收到的 PPP 数据帧的数据域的最大值。通常情况下这个参数
选项使用默认值（1500 字节），因此在 Config-Request 报文中双方都不会携
带这个配置参数选项。 当在某些特殊应用中，可能会使用到小于 1500 字节或
大于 1500 字节的情况，这时在 Config-Request 报文就会携带要协商的 MRU 配
置参数选项值。
CRC 校验域主要是对 PPP 数据帧传输的正确性进行检测的，当然在数据帧中
引入了一些传输的保证机制是好的，但可以反过来说，同样我们会引入更多
的开销，这样可能会增加应用层交互的延迟。
为了能适应复杂多变的网络环境，PPP 协议提供了一种链路控制协议来配置和
测试数据通信链路，它能用来协商 PPP 协议的一些配置参数选项；处理不同
大小的数据帧；检测链路环路、一些链路的错误；终止一条链路。
PPP 的网络控制协议根据不同的网络层协议可提供一族网络控制协议(NCP)，
常用的有提供给 TCP/IP 网络使用的 IPCP 网络控制协议；提供给 SPX/IPX 网
络使用的 IPXCP 网络控制协议等。最为常用的是 IPCP 协议，当点对点的两端
进行 NCP 参数配置协商时，主要是用来通信双方的网络层地址。
校验IP数据报文0x0021
校验LCP数据报文0xC021
校验NCP数据报文0x8021
协议域长度为2个字节，主要用来指明信息域中使用的协
议类型。该域的结构与ISO3309地址域扩展机制一致。
PPP数据帧所承载的几种常见的报文
数据通信设备（在本文中指路由器）的两端如果希望通过 PPP 协议建立点对
点的通信，无论哪一端的设备都需发送 LCP 数据报文来配置链路（测试链
路）。一旦 LCP 的配置参数选项协商完后，通信的双方就会根据 LCP 配置请
求报文中所协商的认证配置参数选项来决定链路两端设备所采用的认证方式。
协议缺省情况下双方是不进行认证的，而直接进入到 NCP 配置参数选项的协
商，直至所经历的几个配置过程全部完成后，点对点的双方就可以开始通过
已建立好的链路进行网络层数据报文的传送了，整个链路就处于可用状态。
只有当任何一端收到 LCP 或 NCP 的链路关闭报文时（一般而言协议是不要求
NCP 有关闭链路的能力的，因此通常情况下关闭链路的数据报文是在 LCP 协
商阶段或应用程序会话阶段发出的）；物理层无法检测到载波或管理人员对
该链路进行关闭操作，都会将该条链路断开，从而终止 PPP 会话。以下是 PPP
协议整个链路过程需经历阶段的状态转移图说明：
在点对点链路的配置、维护和终止过程中，PPP 需经历以下几个阶段：
链路不可用阶段。有时也称为物理层不可用阶段，PPP 链路都需从这个阶段开
始和结束。当通信双方的两端检测到物理线路激活（通常是检测到链路上有
载波信号）时，就会从当前这个阶段跃迁至下一个阶段（即链路建立阶段）。
先简单提一下链路建立阶段，在这个阶段主要是通过 LCP 协议进行链路参数
的配置，LCP 在此阶段的状态机也会根据不同的事件发生变化。当处于在链
路不可用阶段时，LCP 的状态机是处于 initial（初始化状态）或 starting（准备
启动状态），一旦检测到物理线路可用，则 LCP 的状态机就要发生改变。当
链路不可用阶段 链路建立阶段
验证阶段
网络层协议阶段
链路终止阶段
失败
LCP报文
可选，由配置决定
PPP状态转移图
然链路被断开后也同样会返回到这个阶段，往往在实际过程中这个阶段所停
留的时间是很短的，仅仅是检测到对方设备的存在。
链路建立阶段。是 PPP 协议最关键和最复杂的阶段。该阶段主要是发送一些
配置报文来配置数据链路，这些配置的参数不包括网络层协议所需的参数。
当完成数据报文的交换后，则会继续向下一个阶段跃迁，该下一个阶段既可
是验证阶段，也可是网络层协议阶段，下一阶段的选择是依据链路两端的设
备配置的（通常是由用户来配置，但对 NAS 或 BAS 设备的 PPP 模块缺省就需
要支持 PAP 或 CHAP 中的一种认证方式）。在此阶段 LCP 的状态机会发生两
次改变，前面我们说了当链路处于不可用阶段时，此时 LCP 的状态机处于
initial 或 starting，当检测到链路可用时，则物理层会向链路层发送一个 UP 事
件，链路层收到该事件后，会将 LCP 的状态机从当前状态改变为 Request-Sent
（请求发送状态），根据此时的状态机 LCP 会进行相应的动作，也即是开始
发送 Config-Request 报文来配置数据链路，无论哪一端接收到了 Config-Ack
报文时，LCP 的状态机又要发生改变，从当前状态改变为 opened 状态，进入
Opened 状态后收到 Config-Ack 报文的一方则完成了当前阶段，应该向下一个
阶段跃迁。同理可知，另一端也是一样的，但须注意的一点是在链路配置阶
段双方是链路配置操作过程是相互独立的。如果在该阶段收到了非 LCP 数据
报文，则会将这些报文丢弃。
验证阶段。多数情况下的链路两端设备是需要经过认证后才进入到网络层协
议阶段，缺省情况下链路两端的设备是不进行认证的。在该阶段支持 PAP 和
CHAP 两种认证方式，验证方式的选择是依据在链路建立阶段双方进行协商的
结果。然而，链路质量的检测也会在这个阶段同时发生，但协议规定不会让
链路质量的检测无限制的延迟验证过程。在这个阶段仅支持链路控制协议、
验证协议和质量检测数据报文，其它的数据报文都会被丢弃。如果在这个阶
段再次收到了 Config-Request 报文，则又会返回到链路建立阶段。
网络层协议阶段。一旦 PPP 完成了前面几个阶段，每种网络层协议（IP、IPX
和 AppleTalk）会通过各自相应的网络控制协议进行配置，每个 NCP 协议可在
任何时间打开和关闭。当一个 NCP 的状态机变成 Opened 状态时，则 PPP 就
可以开始在链路上承载网络层的数据包报文了。如果在个阶段收到了
Config-Request 报文，则又会返回到链路建立阶段。
网络终止阶段，PPP 能在任何时候终止链路。当载波丢失、授权失败、链路质
量检测失败和管理员人为关闭链路等情况均会导致链路终止。链路建立阶段
可能通过交换 LCP 的链路终止报文来关闭链路，当链路关闭时，链路层会通
知网络层做相应的操作，而且也会通过物理层强制关断链路。对于 NCP 协议，
它是没有也没有必要去关闭 PPP 链路的。
LCP 数据报文是在链路建立阶段被交换的，它作为 PPP 的净载荷被封装在
PPP 数据帧的信息域中。在链路建立阶段的整个过程中信息域的内容是在变化
的，它包括很多种类型的报文，所以这些报文也要通过相应的字段来区分，PPP
数据帧的协议域固定填充 0xC021。
代码域的长度为一个字节，主要是用来标识 LCP 数据报文的类型的。在链路
建立阶段时，接收方收到 LCP 数据报文的代码域无法识别时，就会向对端发
送一个 LCP 的代码拒绝报文（Code-Reject 报文）。
标识域也是一个字节，其目的是用来匹配请求和响应报文。一般而言在进入
链路建立阶段时，通信双方无论哪一端都会连续发送几个配置请求报文
（Config-Request 报文），而这几个请求报文的数据域可能是完全一样的，而
仅仅是它们的标识域不同罢了。通常一个配置请求报文的 ID 是从 0x01 开始逐
步加 1 的，当对端接收到该配置请求报文后，无论使用何种报文（回应报文可
能是 Config-Ack、Config-Nak 和 Config-Reject 三种报文中的一种）来回应对
方，但必须要求回应报文中的 ID（标识域）要与接收报文中的 ID 一致，当通
信设备收到回应后就可以将该回应与发送时的进行比较来决定下一步的操作。
长度域的内容 = 总字节数据（代码域+标志域+长度域+数据域）。长度域所指
示字节数之外的字节将被当作填充字节而忽略掉，而且该域的内容不能超过
MRU 的值。
数据域的内容依据不同 LCP 数据报文的内容也是不一样的。
信息域协议域
标识域代码域 长度域 数据
长度域类型域 数据
PPP封装格式
LCP数据报
文的封装格
式
LCP数据报文
中配置参数选
项的封装格式
0xC021
LCP协议数据报文的格式
链路配置报文
用来建立和配置一条链路，主要包括Conf i gur e- Request 、
Conf i gur e- Ack、Conf i gur e- Nak和Conf i gur e- Rej ect 报文
链路终止报文
用来终止一条链路，主要包括Ter mi nat e- Request 和
Ter mi nat e- Rel py报文
链路维护报文
用来管理和调试链路，主要包括Code- Rej ect 、Pr ot ocol -
Rej ect 、Echo- Request 、Echo- Repl y和Di scar d- Request 报
文
LCP协议数据报文的分类
0x01
0x02
0x03
0x04
0x05
0x06
0x07
0x08
0x09
0x0A
0x0B
0x0C
Configure-Request
Configure-Ack
Configure-Nak
Configure-Reject
Terminate-Request
Terminate-Reply
Code-Reject
Protocol-Reject
Echo-Request
Echo-Reply
Discard-Request
Reserved
LCP协议数据报文的种类
链路配置报文举例
7E FF 03 C0 21 01 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08
02 0D 03 06 7E
7E FF 03 C0 21 02 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02
08 02 0D 03 06 7E
假设点对点通信的一端发送了一个Config-Request报文，报文内容如下：
从报文中可以看出这个配置请求报文包括5个配置参数选项。
当对端正确接收到了该报文后，应该回应一个Config-Ack报文，报文内容
如下：
该报文中唯一修改的内容就是代码域（02表示是Config-Ack报文），标识
域与原报文中的一样。
链路配置报文与其它两类报文有着明显的区别，它主要是用来协商链路的配
置参数选项的，因此这种报文的数据域还要携带许多配置参数选项的。
链 路 配 置 报 文 主 要 包 括 Config-Request 、 Config-Ack 、 Config-Nak 和
Config-Reject 四种报文。
当通信双方需要建立链路时，无论哪一方都需要发送 Config-Request 报文并携
带每一端自已所希望协商的配置参数选项。
当接收方收到 Config-Request 报文时，会在剩下的三种类型的报文中选择一种
来响应对方的请求报文，到底选择哪种报文来响应对方需依据以下两个条件：
不能完全识别配置参数选项的类型域，我们知道一个 Config-Request 报文中会
同时携带多个配置参数选项，而对于一个支持 PPP 协议的通信设备也不一定
会支持上表中所有列出的配置选项，即使支持，也可能在实际应用中关闭掉
某些选项功能。（例如：当使用 PPP 协议通信的一端可能将一些无用的配置
选项都关闭了，而仅支持 0x01 和 0x03 两个配置参数选项，因此当对方发送
的 Config-Request 报文中含有 0x04 配置选项时，对于本端而言这个配置参数
选项就无法识别，也即是不支持这个配置参数选项的协商）。
如果能支持完全识别配置参数选项，但接收端也可能不认可 Config-Request 报
文中配置参数选项数据域中的内容（例如：当一端发送魔术字配置参数选项
0x01
0x02
0x03
0x04
0x05
0x06
0x07
0x08
Maximum-
Recive-Unit
Async-Control-
Character-Map
Authentication-
Protocol
Quality-Protocol
Magic-Number
Address-And-Control-Field-
Compression
Reserved
Protocol-Field-
Compression
配置参数选项的种类
中的魔术字为全 0，而对端认为应该为其它值，这种情况就属于不支持配置参
数选项中的内容）。
所以依据上面的两个条件，我们就可以明确在回应对方配置请求报文时，采
用何种报文回应。
当接收 Config-Request 报文的一端能识别发送过来的所有配置参数选项且认
可所有配置参数选项数据域的内容时，接收端将会给对端回一个 Config-Ack
报文并将配置请求报文中的配置参数选项原封不动的放置在 Config-Ack 报文
的数据域内（根据协议的规定是不可改变配置参数选项的顺序）。当配置请
求报文的发送端收到 Config-Ack 报后，则会从当前阶段进入到下一个阶段。
链路配置报文举例
7E FF 03 C0 21 01 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08
02 0D 03 06 7E
7E FF 03 C0 21 02 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02
08 02 0D 03 06 7E
假设点对点通信的一端发送了一个Config-Request报文，报文内容如下：
从报文中可以看出这个配置请求报文包括5个配置参数选项。
当对端正确接收到了该报文后，应该回应一个Config-Ack报文，报文内容
如下：
该报文中唯一修改的内容就是代码域（02表示是Config-Ack报文），标识
域与原报文中的一样。
一次交互
1
2
Config-Request
Config-Ack
路由器A 路由器B
链路配置报文（一）
当接收 Config-Request 报文的一端能识别发送端所发送过来的所有配置参数
选项，但对部分配置参数选项数据域中的内容不认可时，接收端将会给对端
回应一个 Config-Nak 报文，该报文中只携带不认可的配置参数选项，而这些
配置参数选项的数据内容为本端希望的值。然而当接收端收到 Config-Nak 报
文后，会重新发送 Config-Request 报文，而这个 Config-Request 报文与上一次
所发送的 Config-Request 报文区别在于那些被对端不认可的配置参数选项的
内容被填写到刚刚协商完后再次发送的 Config-Request 报文中（Config-Nak 报
文发送回来的那些配置参数选项）。
链路配置报文举例
假设点对点通信的一端发送了一个Config-Request报文，报文内容如下：
7E FF 03 C0 21 01 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D
03 06 7E
该数据报文中有下划线的配置参数选项的内容为对端不认可的。
当对端正确接收到了该报文后，发现类型域为0x02的配置参数选项可识别，但
该配置参数选项数据域的内容不认可，应发送一个Config-Nak报文且该报文中
将携带希望的配置参数选项内容，报文内容如下：
7E FF 03 C0 21 03 01 00 0A 02 06 00 0E 00 00 7E
该报文中返回的值已经被更改，且当发端收到该报文后会重新发送一个
Config-Request报文，报文内容如下：
7E FF 03 C0 21 01 04 00 17 02 06 00 0E 00 00 05 06 00 0B 42 CB 07 02 08 02 0D
03 06 7E
仔细观察是不是新的配置请求报文与老的配置请求的报文ID不一样。
二次交互（1）
1
2
Config-Request
Config-Nak
路由器A 路由器B
3
4
Config-Request
Config-Ack
链路配置报文（二）
当接收 Config-Request 报文的一端不能识别所有的发送端发送过来的配置参
数选项时，此时接收端将会向对端回一个 Config-Reject 报文，该报文中的数
据域只携带那些不能识别的配置参数选项（当配置参数选项的类型域不识别
时 ） 。 当 对 端 接 收 到 Config-Reject 报 文 后 ， 同 样 会 再 次 发 送 一 个
Config-Request 报文，这个配置请求报文与上一次发送的区别在于将不可识别
的那些配置参数选项给删除了。
链路配置报文举例
7E FF 03 C0 21 01 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08
02 0D 03 06 7E
假设点对点通信的一端发送了一个Config-Request报文，报文内容如下：
下划线所表示的配置参数选项为对端不可识别的。
当对端正确接收到了该报文后，发现类型域为0x02的配置参数选项不识
别，应该回应一个Config-Reject报文，报文内容如下：
7E FF 03 C0 21 04 01 00 0A 02 06 00 0A 00 00 7E
该报文如果被原发送端接收后，又会重新发送一个Config-Request报文，
报文内容如下：
7E FF 03 C0 21 01 04 00 11 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E
这时我们能看到，类型域为02的配置选项在下一次的请求报文中被删除了。
二次交互（2）
1
2
Config-Request
Config-Reject
路由器A 路由器B
3
4
Config-Request
Config-Ack
链路配置报文（三）
链路配置阶段也可能要经过几次协商后才能完成，但这与点对点两端的设备
有着密切的联系。对于 PPP 的两个端点而言，两者是独立完成各自的配置参
数选项的协商过程的。
多次交互
1
2
Config-Request
Config-Reject
路由器A 路由器B
3
4
Config-Request
Config-Nak
5
6
Config-Request
Config-Ack
链路配置报文（四）
链路终止报文分为 Terminate-Request 和 Terminate-Reply 两种报文。LCP 报文
中提供了一种机制来关闭一个点对点的连接，想要关断链路的一端会持续发
送 Terminate-Request 报文，直到收到一个 Terminate-Reply 为止。接收端一旦
收到了一个 Terminate-Request 报文后，必须回应一个 Terminate-Reply 报文，
同时等待对端先将链路断开后，再完成本端的所有断开的操作。
LCP 的链路终止报文的数据域与链路配置报文的数据域不一样，链路终止报
文中无需携带各配置参数选项。对于链路终止报文也同样需要 ID 一致，当接
收到 Terminate-Reply 报文才会做链路终止操作。
链路终止报文
Terminate-Request
Terminate-Reply
魔术字是在 LCP 的 Config-Request 报文中被协商的，并且可被一些其它类型
的 LCP 数据报文所使用，如 Echo-Request、Echo-Reply 报文和 Quality-Protocol
报文等。对于 PPP 协议本身它是不要求协商魔术字的，如果在双方不协商魔
术字的情况下，某些 LCP 的数据报文需要使用魔术字时，那么只能是将魔术
字的内容填充为全 0；反之，则填充为配置参数选项协商后的结果。
魔术字在目前所有的设备当中都是需要进行协商的，它被放在 Config-Request
的配置选项参数中进行发送，而且需要由自身的通信设备独立产生，协议为
了避免双方可能产生同样的魔术字，从而导致通信出现不必要的麻烦，因此
要求由设备采用一些随机方法产生一个独一无二的魔术字。一般来说魔术字
的选择会采用设备的系列号、网络硬件地址或时钟。双方产生相同魔术字的
可能性不能说是没有的，但应尽量避免，通常这种情况是发产在相同厂商的
设备进行互连时，因为一个厂商所生产的设备产生魔术字的方法是一样的。
我们知道魔术字产生的作用是用来帮助检测链路是否存在环路，当接收端收
到 一 个 Config-Request 报 文 时 ， 会 将 此 报 文 与 上 一 次 所 接 收 到 的
Config-Request 进行比较，如果两个报文中所含的魔术字不一致的话，表明链
路不存在环路。但如果一致的话，接收端认为链路可能存在环路，但不一定
存在环路，还需进一步确认。此时接收端将发送一个 Config-Nak 报文，并在
该 报 文 中 携 带 一 个 重 新 产 生 的 魔 术 字 ， 而 且 此 时 在 未 接 收 到 任 何
Config-Request 或 Config-Nak 报 文 之 前 ， 接 收 端 也 不 会 发 送 任 何 的
Config-Request 报文。这时我们假设可能会有以下两种情况发生：
1. 链路实际不存在环路，而是由于对方在产生魔术字时与接收端产生的一
致，但实际这种情况出现的概率是很小的。当 Config-Nak 被对端接收到
后，应该发送一个 Config-Request 报文（此报文中的魔术字为 Nak 报文中
的），当对端接收到后，与上次比较，由于接收端已经在 Nak 报文中产
生了一个不同的魔术字，此时接收端收到的 Config-Request 报文中的魔术
字与上次配置请求报文中不一样，所以接收端可断定链路不存在环路。
2. 链路实际上确实存在环路，一段时间后 Config-Nak 报文会返回到发送该
报文的同一端。这时接收端比较这个 Config-Nak 报文与上一次发出去的
一样，因此链路存在环路的可能性又增大了。我们知道当一端收到了一
个 Config-Nak 报文时，又会发送一个 Config-Request 报文（该报文中的
魔术字与 Config-Nak 中的一致），这样又回到了最初的状态，在这条链
路上就会不断的出现 Config-Request、Config-Nak 报文，因此这样周而复
始下去，接收端就会认为 PPP 链路存在环路的可能性在不断增加，当达
到一定数量级时，就可认为此链路存在环路。
但在实际应用中根据不同设备实现 PPP 协议的方法，我们在链路环路检测时
可采用两种方法。第一种机制就是如上面所述的，这个过程不断地重复，最
终可能会给 LCP 状态机发一个 Down 事件，这时可能会使 LCP 的状态机又回
到初始化阶段，又开始新一轮的协商。当然对于某些设备还会采用第二种机
制，就是不产生任何事件去影响当前 LCP 的状态机，而是停留在请求发送状
态。但这时认为链路有环路的一端设备需要不断的向链路上发送 Echo-Request
报文来检测链路环路是否被解除，当接收端收到 Echo-Reply 报文时，就认为
链路环路被解除，从而就可能进行后续的 PPP 的过程。
PPP 协议也提供了可选的认证配置参数选项，缺省情况下点对点通信的两端是
不进行认证的。在 LCP 的 Config-Request 报文中不可一次携带多种认证配置
选项，必须二者择其一（PAP/CHAP）。一般是在 PPP 设备互连的设备上进行
配置的，或设备默认支持一个缺省的认证方式（PAP 是大部分设备所默认的
认证方式）。当对端收到该配置请求报文后，如果支持配置参数选项中的认
证方式，则回应一个 Config-Ack 报文；否则回应一个 Config-Nak 报文，并附
带上自希望双方采用的认证方式。当对方接收到 Config-Ack 报文后就可以开
始进行认证了，而如果收到得是 Config-Nak 报文，则根据自身是否支持
Config-Nak 报文中的认证方 式 来回应 对 方，如 果支持则回应一个新的
Config-Request（并携带上 Config-Nak 报文中所希望使用的认证协议），否则
将回应一个 Config-Reject 报文，那么双方就无法通过认证，从而不可能建立
起 PPP 链路。
PPP 支持两种授权协议：PAP（Password Authentication Protocol）和 CHAP
（Challenge Hand Authentication Protocol）。
我们所知两个设备在使用 PAP 进行认证之前，应该确认那一方是验证方，那
一方是被验证方。实际上对于使用 PPP 协议互连的两端来说，既可作为认证
方，也可作为被认证方。但通常情况下，PAP 只使用一个方向上的认证。一
般在两端设备使用 PAP 协议之前，均会设备上进行一些相应的配置，对于
MA5200IP 接 入 设 备 ， 它 默 认 就 作 为 验 证 方 ， 但 可 通 过 使 用 命 令 PAP
Authentication PAP/CHAP 来更改认证方式，而对于被验证方而言只需设置用
户名和密码即可。
PAP 认证是两次握手，在链路建立阶段，依据设备上的配置情况，如果是使
用 PAP 认证，则验证方在发送 Config-Request 报文时会携带认证配置参数选
项，而对于被验证方而言则是不需要，它只需要收到该配置请求报文后根据
自身的情况给对端返回相应的报文。如果点对点的两端设备采用的是 PAP 双
向认证时，也即是它同时也作为验证方，则此时需要在配置请求报文中携带
认证配置参数选项。因此，我们可以总结一下，如果对于点对点的两个设备
在 PPP 链路建立的过程中使用的认证方式为 PAP 的话，那么验证方在其
Config-Request 报文中必须含有认证配置参数选项，且该认证配置参数选项的
数据域为 0xC023 。
当通信设备的两端在收到对方返回的 Config-Ack 报文时，就从各自的链路建
立阶段进入到认证阶段，那么作为被验证方此时需要向验证方发送 PAP 认证
的请求报文，该请求报文携带了用户名和密码，当验证方收到该认证请求报
文后，则会根据报文中的实际内容查找本地的数据库，如果该数据库中有与
用户名和密码一致的选项时，则回向对方返回一个认证请求响应，告诉对方
认证已通过。反之，如果用户名与密码不符，则向对方返回验证不通过的响
应报文。如果双方都配置为验证方，则需要双方的两个单向验证过程都完成
后，方可进入到网络层协议阶段，否则在一定次的认证失败后，则会从当前
状态返回链路不可用状态。
例如：当路由器 A（被验证方）收到了路由器 B 的 Config-Ack 报文后，因为
是使用 PAP 认证，所以作为被验证方的路由器 A 应主动向验证方（路由器 B）
发送认证请求报文（PAP Authenticate），用户名和密码均为 163，报文的内容
如下：
7E FF 03 C0 23 01 01 00 0C 03 31 36 33 03 31 36 33 7E
下划线的前四个字节是用户名，后四个字节是密码。
当路由器 B 收到了该报文后，会向路由器 A 回应一个 PAP Authenticate Ack 报
文，报文内容如下：
7E FF 03 80 21 02 01 00 05 00 7E
此时所回应的报文中，并未携带任何数据，如果是认证不通过，则会在返回
的报文中指是因何原因无法认证通过，可能是无此用户名或密码不匹配。
与 PAP 认证比起来，CHAP 认证更具有安全性，从前面认证过程的数据包交
换过程中不难发现，采用 PAP 认证时，被验证是采用明文的方式直接将用户
名和密码发送给验证方的，而对于 PAP 认证则不一样。
CHAP 为三次握手协议，它只在网络上传送用户名而不传送口令，因此安全性
比 PAP 高。在验证一开始，不像 PAP 一样是由被验证方发送认证请求报文了，
而是由验证方向被验证方发送一段随机的报文，并加上自己的主机名，我们
通称这个过程叫做挑战。当被验证方收到验证方的验证请求，从中提取出验
证方所发送过来的主机名，然后根据该主机名在被验证方设备的后台数据库
中去查找相同的用户名的记录，当查找到后就使用该用户名所对应的密钥，
然后根据这个密钥、报文 ID 和验证方发送的随机报文用 Md5 加密算法生成应
答，随后将应答和自己的主机名送回，同样验证方收到被验证方发送回应后，
提取被验证方的用户名，然后去查找本地的数据库，当找到与被验证方一致
用户名后，根据该用户名所对应的密钥、保留报文 ID 和随机报文用 Md5 加密
算法生成结果，和刚刚被验证方所返回的应答进行比较，相同则返回 Ack，否
则返回 Nak。
例 11： 如图 4-2 所示，当路由器 A（被验证方）收到了路由器 B 的 Challenge
报文后，报文内容如下：
7E FF 03 C2 23 01 01 00 1C 10 FF 41 CF 22 AA 8E F1 B9 99 9A 79 A7 56 78 C4
A7 4d 41 35 32 30 30 417E
下划线的前 16 个字节是验证方随机产生的一段报文，后 7 个字节是验证方的
主机名（MA5200A），而且单个字节 10 表示随机报文的长度。
而此时路由器 A 会根据用户名所对应的密钥使用报文的 ID 和该报文的内容
生成一个回应报文，报文内容如下：
7E FF 03 C2 23 02 01 00 1F 10 18 86 22 FF CE 81 D0 68 FF 80 85 00 A7 E3 85 35
70 70 6B 69 73 73 40 68 75 61 7E
我们将这个回应报文与验证方发送的挑战报文进行比较，报文的代码域已由
原 01 改为 02，总报文的长度有变化，主要后而一个下划线的内容是被验证方
的主机名（ppkiss@hua），而且此时回应的 16 个字节的报文已经是经过 MD5
算法加密过的。
当 验 证 方 收 到 了 这 个 回 应 报 文 后 ， 会 根 据 报 文 中 被 验 证 方 的 主 机 名
（ppkiss@hua）在本地的数据库中去查找密钥，然后再对原发先发送的那段挑
战报文进行 MD5 的算法加密，如果所得的结果与对方刚发过来的 16 个字节
的加密值一样的话，则就会发送一个报文通知被验证方，你的认证已经通过，
我们可以进入到下一个阶段了。在实际应用当中，我们很多都是使用 PC 机来
进行拨号这个过程，实际中当验证方发送挑战后，PC 机只接收而并不去查本
地数据库，而直接使用在拨号对话框中所输入的密码和报文的 ID 及报报文的
内容进行 MD5 算法加密（这个在 PC 机采用 PPPOE 软件拨入到 MA5200 时就
是这样的）。
下面来看一下验证通过时，验证方给被验证方所发送的一段报文内容：
7E FF 03 C2 23 03 01 00 17 57 65 6C 63 6F 6D 65 20 74 6F20 4D 41 35 32 30 30 41
2E 7E
此时所回应的报文的代码域为 03，且报文的实际内容是，Welcom to MA5200A。
NCP 协议的数据报文是在网络层协议阶段被交换的，在这个阶段所需的一些
配置参数选项协商完后，就可以进行网络层的通信，也即是在点对点的链路
上可以开始传送网络层的数据报文了。NCP 协议主要包括 IPCP、IPXCP 等，
但我们在实际当中最常遇见的也只有 IPCP 协议了，如果对 IPXCP 或其它的一
些网络控制协议有兴趣，则可参见 RFC1552。
IPCP
IPXCP
AppleTalk
NCP协议的分类
IPCP 控制协议主要是负责完成 IP 网络层协议通信所需配置参数的选项协商
的。IPCP 在运行的过程当中，主要是完成点对点通信设备的两端动态的协商
IP 地址。我们依据两端设备的配置选项可将 IPCP 的协商过程分为"静态"和"动
态"。何为静态，何为动态，这是一个相对的概念，可能不太准确，只作为参
考使用。我们在下面会具体描述这两个过程。IPCP 的数据的文同 LCP 的数据
报文非常类似，只不过 NCP 是在网络层协议阶段协商配置参数选项，
而 LCP 协议则是在链路建立阶段协商配置参数选项的。除此之外是两者在所
使用报文上的相似之处，我们知道 LCP 共包括十几种报文，而 IPCP 也包括多
种报文，但它的报文类型只是 LCP 数据报文的一个子集（只有 LCP 代码域从
1 到 7 这七种报文），而且实际的数据报文交换过程中也仅涉及以下几种：
Config-Request、Config-Ack、Config-Nak 和 Config-Reject（代码域从 1 到 4，
而链路终止报文一般而言是不在网络协议阶段使用的，而且也是不需要的）。
以下就具体介绍一下 IPCP 控制协议的静态和动态的两个过程，实际上两者的
区分是在于互连设备 IP 地址的获取过程。
静态协商，也即是不协商。点对点的通信设备两端在 PPP 协商之前已配置好
了 IP 地址，所以就无须在网络层协议阶段协商 IP 地址，而双方唯一要做的就
是告诉对方自身的 IP 地址。在 IPCP 控制协议完成整个配置的过程时，最理想
的情况将会看到如图所示的四种报文，而无其它报文再被发送。如果当配置
请求中所携带的网络层配置参数选项类似于 LCP 配置参数选项协商过程一样，
点对点通信设备均设置了IP地址
我知道了
我的IP地址
是
路由器B路由器A
我知道了
我的IP地址
是
I PCP静态地址协商
可能会有对方不识别的配置参数选项或不被对方所认可的配置参数选项的内
容。这样在这个阶段的协商过程中可能还会看到其它的一些报文。
在静态协商时，如果 IPCP 的 Config-Request 报文中只含有地址配置参数选项
时（实际中可能还会附带其它配置参数选项，这些配置参数选项的协商与 LCP
阶段的一样，而我这里只提到了 IP 地址配置参数选项），无论是发送方还是
接收方都同时发送 Config-Request 报文，其中配置选项中只含有各自的 IP 地
址。当对端收到该报文后，会发送一个 Config-Ack 报文，这个目的是告诉对
端我已经知道了你的 IP 地址，对路由器而言会增加一条到对端接口的主机路
由。 刚进入网络层协议阶段时，IPCP 的状态机是 initial 的，但当完成了上述
的整个过程后，IPCP 的状态机改变为 Opened，双方也就可以开始网络层数据
网的传送了。
当一端接收到 Config-Request 报文后，它从报文的配置参数选项中可获知对端
的 IP 地址，但并不与本端的 IP 地址进行比较。我们也知道，一般而言点对点
的两端应该是在一个网段。但如果双方的地址不在一个网段，IPCP 协议中并
未规定，此时不给对方回应 Config-Ack 报文，而是无条件的回送。因此说点
对点通信的两端如果是手动设置每一端的 IP 地址时，无须双方地址在同一网
段。
例 8：假设 IPCP 在网络层协议阶段开始协商配置参数选项（这里只举协商 IP
地址的配置参数选项地的过程），发送方设置 IP 地址为 ，接收方
设置 IP 地址为 ，发送方发送给 Config-Request 报文内容如下：
7E FF 03 80 21 01 01 00 0A 03 06 C0 A8 00 01 7E
在这个例子中我们能看见明显的改变之处再于 PPP 协议域字段由原先的
0xC021 改变为 0x8021，下划线的部分表示本端的 IP 地址。
当对端正确接收到了该报文后，应该回应一个 Config-Ack 报文，报文内容如
下：
7E FF 03 80 21 02 01 00 0A 03 06 C0 A8 00 01 7E
Sender Reciever
Config-Request
Config-Request
Config-Ack
Config-Ack
同样的接收方给发送方也发送一个 Config-Request 报文内容如下，但此时报文
中 IP 地址配置参数选项的值为本端的 IP 地址（）：
7E FF 03 80 21 01 01 00 0A 03 06 C0 A8 00 02 7E
发送方回应一个 Config-Ack 报文给接收方，报文内容如下：
7E FF 03 80 21 02 01 00 0A 03 06 C0 A8 00 02 7E
动态协商，也即是一端配置为动态获取 IP 地址，另一端通过手动方式配置 IP
地址，且允许给对端分配 IP 地址，这个过程实际上可与窄带拨号上网的过程
相一致，如果我们想用计算机上网，均会安装一个拨号适配器，而且计算机
中的拨号网络适配器是采用动态获取 IP 地址的方式，也就是在 IPCP 的
Config-Request 报文中只携带 IP 地址的配置参数选项。
这
个
例
子
与
一
个
例
子
相
似
如果是配置参数选项中含有其它配置参数选项，则可能会遇到其它的一些情况
（如不识别配置参数选项的代码域或不认可配置参数选项的内容，但对于这
点对点通信的一方设置了IP地址，而
另一方则通过从对端获取IP地址
这个地址不合法，用
这个地址吧
我的IP地址是
路由器B路由器A
我知道了
我的IP地址是
我的IP地址是
我知道了
I PCP动态地址协商
Sender Receiver
Config-Request
Config-Request
Config-Nak
Config-Ack
Config-Request
Config-Ack
些情况的处理方法和 LCP 配置参数选项的处理方法一致）。图我们可以看出
发送方连续发送了两次 Config-Request 报文，才能完成发送方的协商过程。而
接收方仍然只需要发送一次 Config-Request 即可完成本端的协商过程。
由于发送方没有配置 IP 地址（而是动态获取 IP 地址），所以在 IPCP 的
Config-Request 报文的 IP 地址配置参数配置选项中的 IP 地址填充全 0（也即
是 ），这样当对端收到这个 Config-Request 报文时，当接收方收到该配
置请求报文后会迅检测 IP 地址的内容，如果发送为全 0，则认为对端的这个 IP
地址不是我所希望的值，这样就回应一个 Config-Nak 报文，并将希望分配给
对方的 IP 地址填充到 Config-Nak 报文内。这时当接收方收到 Config-Nak 报文
后，就会重新发送一个 Config-Request 报文，这个报文中的 IP 地址配置选项
为对方在 Nak 报文中所提供的。
接收方 IP 地址的配置过程与静态时的一样，只需发送一个 Config-Request 报
文即可，当收到发送方的 Config-Ack 报文，就表示接收方的 IP 地址配置完成。
例 9： 假设 IPCP 在网络层协议阶段开始协商配置参数选项（这里只举协商 IP
地址的配置参数选项地的过程），发送方没有配置 IP 地址，而接收方配置了
IP 地址为 ，接收方可给发送方分配 IP 地址（），发送
方发送给接收方的 Config-Request 报文内容如下：
7E FF 03 80 21 01 01 00 0A 03 06 00 00 00 00 7E
有下划线的部分表示本端的 IP 地址。
当对端正确接收到了该报文后，应该回应一个 Config-Nak 报文，报文内容如
下：
7E FF 03 80 21 03 01 00 0A 03 06 C0 A8 00 01 7E
当接收方收到该报文后，重新发送一个 Config-Request 报文，报文内容如下：
7E FF 03 80 21 01 02 00 0A 03 06 C0 A8 00 01 7E
接 收 方 再 次 收 到 发 送 方 的 一 个 Config-Request 报 文 ， 此 时 将 回 应 一 个
Config-Ack 报文，报文内容如下：
7E FF 03 80 21 02 02 00 0A 03 06 C0 A8 00 01 7E
请仔细观察一下这些报文在交互过程中，PPP 数据帧净载荷内的数据报文的类
型域和报文 ID。
同样的接收方给发送方也发送一个 Config-Request 报文，报文内容如下：
7E FF 03 80 21 01 01 00 0A 03 06 C0 A8 00 02 7E
发送方应回送一个 Config-Ack 给接收方，报文内容如下：
7E FF 03 80 21 02 01 00 0A 03 06 C0 A8 00 02 7E
小节（一）
PPP协议的三组件包括PPP协议的封装方式、LCP协议和NCP协议
PPP协议是数据链路层协议，它的数据帧封装格式非常类似于
HDLC
PPP协议可通过协议域来区分数据域中净载荷的数据类型
PPP协议通过LCP协议完成数据链路的配置和测试
PPP协议通过NCP协议完成点对点通信设备之间网络层通信所需参
数的配置
小节（二）
魔术字可以在链路配置阶段被协商，数据报文可借助魔术字来检
PPP链路是否存在环路
PAP（密码认证协议）认证是二次握手，它是直接在网络上传送
明文的用户名和密码，因此这种协议安全性不高
CHAP（挑战性握手认证协议）认证是三次握手，它只在网络上
传送验证方和被验证方的主机名，而并不传送密码，因此相比之处
CHAP比PAP更安全
PPP协议缺省的MRU是1500，而对于通信的双方可根据实际需要
对MRU进行协商
小节（三）
PPP协议的状态转移图包括链路不可用阶段、链路建立阶段、认证阶
段、网络层协议阶段和链路终止阶段
LCP协议依据报文的功能可分为链路配置报文、链路终止报文和链路
维护报文
LCP协议的链路配置报文主要是用来协商一些可选的配置参数选项
LCP协议的链路终止报文主要是用来终止一条PPP链路
LCP协议的链路维护报文主要是用来测试和调试PPP链路
NCP协议主要负责网络层配置参数选项的协商，它包括"静态协商"和
"动态协商"
第3章 PPPOE 协议
PPPOE协议
PPP协议
SLIP协议
内容提要
随着宽带网络技术的不断发展，以 xDSL、CableModem 和以太网为主的几种
主流宽带接入技术的应用已开展的如火如荼。同时又给各大网络运营商们带
来了种种困惑，无论使用哪种接入技术，对于他们而言可盼和可求的是如何
有效的管理用户，如何从网络的投资中收取回报，因此对于各种宽带接入技
术的收费的问题就变得更加敏感。在传统的以太网模型中，我们是不存在所
谓的用户计费的概念，要么用户能设置/获取 IP 地址上网，要么用户就无法上
网。IETF 的工程师们在秉承窄带拨号上网的运营思路（使用 NAS 设备终结用
户的 PPP 数据包），制定出了在以太网上传送 PPP 数据包的协议（Point To
Point Protocol Over Ethernet），这个协议出台后，各网络设备制造商也相继推
出自已品牌的宽带接入服务器（BAS），它不仅能支持 PPPOE 协议数据报文
的终结，而且还能支持其它许多协议。如华为公司的 MA5200IP 接入设备和
ISN8850 智能多业务交换机。
PPPOE 协议提供了在广播式的网络（如以太网）中多台主机连接到远端的访
问集中器（我们对目前能完成上述功能的设备为宽带接入服务器）上的一种
标准。在这种网络模型中，我们不难看出所有用户的主机都需要能独立的初
始化自已的 PPP 协议栈，而且通过 PPP 协议本身所具有的一些特点，能实现
在广播式网络上对用户进行计费和管理。为了能在广播式的网络上建立、维
持各主机与访问集中器之间点对点的关系，那么就需要每个主机与访问集中
器之间能建立唯一的点到点的会话。
PPP协议要求进行通信的双方之间是点到点的关系，不
适于广播型的以太网和另外一些多点访问型的网络，于
是就产生了PPPOE协议(Point-to-Point Protocol Over
Ethernet)。它不仅为使用桥接以太网接入的用户提供了
一种宽带接入手段，同时还能提供方便的接入控制和计
费。每个接入用户均建立一个独一无二PPP的会话，因
此会话建立之前必需知道远端访问集中设备的MAC地址，
PPPOE协议可通过发现协议来获取到。
PPPOE协议概述
PPPOE 协议共包括两个阶段，即 PPPOE 的发现阶段（PPPOE Discovery
Stage）和 PPPOE 的会话阶段（PPPOE Session Stage）。这里我们更注重 PPPOE
发现阶段的介绍，因为 PPPOE 的会话阶段和 PPP 的会话过程基本上是一样的，
两者的主要区别在于只是在 PPP 的数据报文前封装了 PPPOE 的报文头。无论
是哪一个阶段的数据报文最终会被封装成以太网的帧进行传送。当一个主机
希望能够开始一个 PPPOE 会话时，它首先会在广播式的网络（也可能还要跨
跃多点访问的网络，如 ATM 等，从而就形成了 PPPOEOA 的数据包）上寻找
一个访问集中器，当然可能网络上会存在多个访问集中器时，对于主机而言
则会根据各访问集中器（AC，Access Concentration）所能提供的服务或用户
的预先的一些配置来进行相应的选择。当主机选择完了所需要的访问集中器
后，就开始和访问集中器建立一个 PPPOE 会话进程。在这个过程中访问集中
器会为每一个 PPPOE 会话分配一个唯一的进程 ID，会话建立起来后就开始
了 PPPOE 的会话阶段，在这个阶段中已建立好点对点连接的双方（这种点对
点的结构与 PPP 不一样，它是一种逻辑上的点对点关系）就采用 PPP 协议来
交换数据报文，从而完成一系列 PPP 的过程，最终将在这点对点的逻辑通道
上进行网络层数据报的传送。
PPPOE协议分为发现阶段和PPP会话阶段。当主机希望开始
一个PPPOE会话时，它首先要执行一个发现过程来识别对
方的MAC地址，然后建立一个唯一的PPPOE会话ID。
PPPOE使用一个发现协议来解决这个问题，它是基于客户/
服务器模型的。由于以太网的广播特性，在这个过程中主机
(客户)能发现所有的访问集中器(服务器)，并选择其中一个，
根据所获信息在两者之间建立点对点的连接。当一个PPP会
话被建立起来之后，就完成了PPPOE的整个发现阶段。
发现阶段
PPPOE的会话阶段开始后，主机和访问集中器之间就依据
PPP协议传送PPP数据，进行PPP的各项协商和数据传输。
在这一阶段传输的数据包中必须包含在发现阶段确定的会话
标识并保持不变。正常情况下，会话阶段的结束是由PPP协
议控制完成的，但在PPPOE中定义了一个PADT 包用来结
束会话，主机或者访问集中器可以在PPP会话开始后的任何
时候通过发送这个数据包来结束会话。
会话阶段
PPPOE 的初始化过程是至关重要的，它不仅要在广播式的网络上确定一对一
的逻辑关系，而且还要为 PPPOE 的会话阶段准备一些必要条件，如访问集中
器唯一分配的会话 ID（Session ID）。在介绍 PPPOE 的发现阶段之前，首先
让我们重温一下以太网帧的封装格式，前面也介绍过了，所有的 PPPOE 的数
据报文均是被封装在以太网的数据域（净载荷区）中传送的。以太网的帧格
式对于大多数人来说是并不陌生，而且目前大多数的网络中都在使用以太网
版，因此 EthernetII 就被作为一种事实上的工业标准而广泛使用，如果对以
太网不太熟悉或想深入了解的读者，可参考相关局域网技术方面的书籍。以
太网目的地址（目的 MAC 地址）和以太网源地址（源 MAC 地址），是我们
大家最为熟悉的数据链路层地址。它包括单播地址、多播地址和广播地址，
而对于 PPPOE 协议中要使用到单播地址和广播地址。在前面也提到了，对于
PPP 这样的数据链路层协议而言，二层地址通信双方之间已失去了原有的意义。
以太网的类型域也是我们最关心的一个字段，它在 1997 年以前还一直由施乐
公司维护，但后来就交由 IEEE802 小组维护了。通过这个字段的内容，数据
包的接收方可以识别以太网的数据域中承载的是什么协议的数据报文。对于
PPPOE 的两大阶段，也正是通过以太网的类型域进行区分的。在 PPPOE 的发
现阶段时，以太网的类型域填充 0x8863；而在 PPPOE 的会话阶段时，以太网
的类型域填充为 0x8864。数据域（净载荷）主要是用来承载类型域中所指示
的数据报文，在 PPPOE 协议中所有的 PPPOE 数据报文就是被封装在这个域中
被传送。校验域，主要用来保证链路层数据帧传送的正确性。
以太网的帧格式
Ä¿µÄµØÖ·
£¨ 6 octets £©
Ố µØÖ·
£¨ 6 octets £©
ÀàÐÍ Óò
£¨ 2 octets £©
¾»Ôغ É
Ö¡ УÑé
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
PPPOE 的数据报文是被封装在以太网帧的数据域内的。简单来说我们可能把
PPPOE 报文分成两大块，一大块是 PPPOE 的数据报头，另一块则是 PPPOE
的净载荷（数据域），对于 PPPOE 报文数据域中的内容会随着会话过程的进
行而不断改变。
PPPOE 的发现阶段可分为四步，其实这个过程也是 PPPOE 四种数据报文的交
换的一个过程。当完成这四步后，用户主机与访问集中器双方就能获知对方
的 MAC 地址和唯一的会话 ID 号，从而进入到下一个阶段（PPPOE 的会话阶
段）。实际上双方在互相知道了对方的 MAC 地址后，就已经在广播式的网络
上确定了一一的对应关系，为了保证这个连接的有效性，同时使 PPPOE 协议
能更加灵活的运用，因此还加入了会话 ID 字段，通过这两个条件就可完成确
定双方点对点的关系。在这个阶段一开始，由于接入用户并不知道访问集中
器的 MAC 地址，则使用类似于 ARP 解析的过程的机制来获取访问集中器的
MAC 地址。首先由接入用户侧发起一个初始化的广播报文，对于访问集中器
如果配置了 PPPOE 的业务时，它会时实检测网络上的数据包，当发现以太网
数据帧中所承载的是 PPPOE 报文时（通过协议域的内容来区分），就会将其
交给相应的模块去处理。当收到初始化报文后，访问集中器会向该用户回应
一个报文。如果网络上存在很多这样的访问集中器且都收到了用户侧发送的
初始化报文时，它们也都会向用户侧会送一个确认报文，如果该用户收到这
个报文后，则会依据报文中所携带的内容或本端的一些配置来选择一个唯一
的访问集中器进行会话。到此时已完成了前两步了，那么剩下的两步则是协
目的地址
源地址
(6字节)
(6字节)
帧类型域
<=1500字
节
净载荷
帧校验
(4字节)
以太网帧格
式
(2字节)
以太网广播地址
PPPOE发现阶段 PPPOE会话阶段
以太网单播地址
主机以太网地址 主机以太网地址
0x8863 0x8864
数据区 数据区
数据帧校验 数据帧校验
PPPOE发现阶段
以太网帧格式
PPPOE会话阶段
以太网帧格式
PPPOE的帧格式（一）
商一些所提供的服务选项和获取 PPPOE 会话阶段所必须的会话 ID 值。在这个
阶段，所有数据报文是被承载在以太网的数据域中的，而且以太网数据帧的
协议域始终为 0x8863。
PPPOE 数据报文的数据区最开始的 4 位为版本域，协议中给出了明确的规定，
这个域的内容填充 0x01。紧接在版本域后的 4 位是类型域，协议中同样规定，
这个域的内容填充为 0x01。代码域占用 1 个字节，对于 PPPOE 的不同阶段这
个域内的内容也是不一样的。会话 ID 点用 2 个字节，当访问集中器还未分配
唯一的会话 ID 给用户主机的话，则该域内的内容必须填充为 0x0000，一旦主
机获取了会话 ID 后，那么在后续的所有报文中该域必须填充那个唯一的会话
ID 值。长度域为 2 个字节，用来指示 PPPOE 数据报文中净载荷的长度。数据
域，有时也称之为净载荷域，在 PPPOE 的不同阶段该域内的数据内容会有很
大的不同。在 PPPOE 的发现阶段时，该域内会填充一些 Tag（标记）；而在
PPPOE 的会话阶段，该域则携带的是 PPP 的报文。
版本 类型 代码 会话ID
长度 净载荷
4 4 8 16
16
发现阶段承载一些标记
会话阶段承载PPP数据报文
PPPOE的帧格式（二）
对于发现阶段的 PPPOE 数据报文而言，它的净载荷可能包含零个或多个 Tag
（标记），实际上这些标记的意义非常类似于 PPP 配置参数选项，它同样也
是要经过协商的。对于 PPPOE 协议而言，没有像 PPP 的配置参数选项那样定
义了很多细节，而只是一个初略的定义，因此在实际当中实现这个过程会依
据不同厂商的设备有不同。
从上图中可以看出，标记的封装格式采用的是大家所熟知的 TLV 结构，也即
是（类型+长度+数据）。
标记的类型域为 2 个字节，下表列出了各种标记类型的含义：
标记类型 标记说明
0x0000 表示PPPOE报文数据域中一串标记的结束，为了保证版本的
兼容性而保留，在有些报文中有应用。
0x0101 服务名，主要用来表明网络侧所能提供给用户的一些服务。
0x0102 访问集中器名，当用户侧接收到了AC的回应的PADO报文时，
就可获从所携带的标记中获知访问集中器的名子，而且还可
以据此来选择相应的访问集中器。
0x0103 主机唯一标识，类似于PPP数据报文中的标识域，主要是用来
匹配发送和接收端的，因为对于广播式的网络中会同时存在
很多个PPPOE的数据报文。
0x0104 AC-Cookies，主要被用来防止恶意性DOS功击。
0x0105 销售商的标识符。
0x0110 中继会话ID，对于PPPOE的数据报文也同样可以像DHCP报文
一样被中断到另外的AC上终结，这个字段则是用来维护另一
个连接的。
TAG
标记类型 16 标记长度 16
标记值
0x0000
0x0102
0x0104
0x0110
0x0101
0x0103
0x0105
0x0201
End-of-list
AC-Name
AC-Cookie
Relay-Session-ID
Service-Name
Service-Name-Error
Host-Uniq
Verdor-Specific
0x0202 0x0203AC-System-Error Generic-Error
PPPOE的帧格式（三）
0x0201 服务名错误，当请求的服务名不被对端所接受时，会在响应
的报文中携带这个标记。
0x0202 访问集中器名出错。
0x0203 一般性错误。
标记的长度域为 2 个字节，它用来指明标记数据域的长度。
标记的数据域中用来放置不同类型标记所对应的相关数据。
上图中每一行后面的数字为该报文的代码值。
PADI(PPPOE发现初始报文)
PADO(PPPOE发现提供报文)
PADR(PPPOE发现请求报文)
PADS(PPPOE发现会话确认报文)
PADT(PPPOE发现终止报文)
09
a7
07
65
19
PPPOE发现阶段数据报文分类
PADI（PPPOE Active Discovery Initiation）是 PPPOE 发现阶段的第一步，也即
是由用户侧首先发送的一个报文。用户主机是以广播的方式发送这个报文，
所以该报文所对应的以太网帧的目的地址域应填充为全 1，而源地址域填充用
户主机的 MAC 地址。广播包可能会被多个访问集中器接收到，后面会讲到对
于接收到 PADI 报文的访问集中器会使用 PADO 报文来回应用户主机。
我们来看一下 PADI 报文中几个域的填充情况，前面已强调过版本域和类型域
固定填充 0x01，因为两个域各占 4 位，所以合并为 1 个字节后应为 0x11。PADI
报文的代码域填充 0x09，会话 ID 填充 0x0000。PADI 报文必须含一个由用户
侧请求的正确服务名标记，当然还可能携带一些其它的标记，而一个完整的
PADI 报文（包括 PPPOE 头）不能超过 1484 个字节，以便能留下足够的空间
给中继代理增加一个中继的会话 ID 标记。
例如：PADI 数据报文
FF FF FF FF FF FF 00 10 A4 97 C1 D9 88 63 11 09 00 00 00 0C 01 03 00 04 01 00
00 00 01 01 00 00
这个报文中包括两个标记：一个是主机的只唯一标识，另一个则是服务名标
记，从上面这个报文中可以看出服务名没有具体实际的内容，说明对于用户
主机可以接受任何由访问集中器所提供的服务。
以太网
1
2
3
目标地址为广播地址0xffffffff，源地址为主机的以太网地
址。ETHER_TYPE值为0x8863，码值为0x09，SESSION-
ID为0x0000。TAG_TYPE：有且仅有一个Service-Name表
明主机请求的服务。任何数量的其他TAG_TYPE。 PADI
报文长度不能超过1484个字节，为Relay-Session-Id TAG留
空间。
PADI 报文
PADO（PPPOE Active Discovery Offer）是 PPPOE 发现阶段的第二步，也即是
由访问集中器回应各用户主机发送的 PADI 报文，此时该报文所对应的以太网
帧的源地址填充访问集中器的 MAC 地址，而目的地址则填充从 PADI 中所获
取的用户主机的 MAC 地址。
我们来看一下 PADO 报文几个域的填充情况，版本域和类型域不变固定填充
0x01，代码域填充 0x07，会话 ID 填充 0x0000。PADO 报文中必须包含一个访
问集中器名这个标记，同时还要包含对 PADI 报文中服务名标记的确认标记和
对其它标记的一些确认标记。这个过程有点类似于 PPP 协议中链路建立过程
中的 Config-Ack 报文，当然如果用户主机所申请的服务访问集中器不支持的
话，则访问集中器就不会回应 PADO 报文。
例如：PADO 数据报文
00 10 A4 97 C1 D9 00 B0 D0 BC AB 75 88 63 11 07 00 00 00 1A 01 02 00 06 4D 44
35 35 30 30 01 03 00 04 01 00 00 00 01 01 00 00 00 00 00 00
这个报文中包括 4 个标记，在 PADI 所提供的标记的基础上又增加了两个标记，
一个是访问集中器名，下划线部分即表示访问集中器名（MD5500），而且还
包含一个标记结束标记。
以太网
1
2
3
目标地址为主机以太网地址。源地址为接入集中器的以太
网地址。ETHER_TYPE值为0x8863，码值为0x07，
SESSION-ID为0x0000，TAG_TYPE：必须有一个含有接
入集中器名字的AC-Name TAG，必须有一个与收到的
PADI相同的Service-Name TAG和任意数量的其他Service-
Name TAG表明集中器可以提供的服务。
PADO报文
PADR（PPPOE Active Discovery Request）是 PPPOE 发现阶段的第三步，也即
是由用户主机向访问服务器发送单播的请求报文。当用户主机收到 PADO 报
文后，会从这些报文中挑选一个访问集中器作为后续会话的对象。由于用户
主机在收到 PADO 报文后，就获知了访问集中器的 MAC 地址，因此 PADR
报文所以应的以太网帧的源地址填充用户主机的 MAC 地址，而以太网的目的
地址填充为访问集中器的 MAC 地址。
我们来看一下 PADR 报文几个域的填充情况，版本域和类型域不变固定填充
0x01，代码域填充 0x19，会话 ID 域填充 0x0000。此时 PADR 报文必须准确
地包含一个服务名的标记，指示用户主机申请的服务和其它的标记类型。
例如：PADR 数据报文
00 B0 D0 BC AB 75 00 10 A4 97 C1 D9 88 63 11 19 00 00 00 0C 01 03 00 04 01 00
00 00 01 01 00 00
当收到访问集中器的 PADO 报文后，用户主机会发送 PADR 报文，该报文所
含的标记域与 PADI 报文中的一致，但些时用户主机已获知了访问集中器名。
以太网
1
2
3
目标地址为接入集中器的以太网地址，源地址为主机的以
太网地址。 ETHER_TYPE值为0x8863，码值为0x19，
SESSION-ID为0x0000，TAG_TYPE： 必须有一个类型为
Service-Name的TAG向集中器指明请求的服务，可以有任
意数量的其他TAG。
PADR报文
PADS（PPPOE Active Discovery Session-confirmation）是 PPPOE 发现阶段的
第四步，也即是最后一步，此时访问集中器当收到 PADR 报文时，就准备进
入开始一个 PPP 的会话了，而此时访问集中器会为在这个会话分配一个唯一
的会话进程 ID，并在发送给主机的 PADS 报文中携带上这个会话 ID。当然如
果访问集中器不满足用户所申请的服务的话，则会向用户发送一个 PADS 报
文，而其中携带一个服务名错误的标记，而且此时该 PADS 报文中的会话 ID
填充 0x0000。
我们来看一下 PADS 报文几个域的填充情况，版本域和类型域不变固定填充
0x01，代码域填充 0x65，会话 ID 必须设为给这个 PPPOE 进程所分配的唯一
值。
例 4：PADS 数据报文
00 10 A4 97 C1 D9 00 B0 D0 BC AB 75 88 63 11 65 01 6B 00 10 01 03 00 04 01 00
00 00 01 01 00 00 00 00 00 00
其中下划线部分为访问集中器给这个 PPPOE 会话分配的唯一会话 ID。
以太网
1
2
3
目标地址为主机的 以太网地址，源地址为接入集中器的以
太网地址。 ETHER_TYPE值为0x8863，码值为0x65，
SESSION-ID为集中器指定的唯一的标识一个PPPOE会话
的值，TAG_ TYPE：包含一个类型为Service-Name的TAG，
表明集中器提供给这个会话的服务，可以包含任意数量的
其他TAG。
PADS报文
PADT（PPPOE Active Discovery Terminate）报文可能在会话进行开始之后的
任意时间内被发送，主要是用来终止一个 PPPOE 会话的止。它可以由主机或
访问集中器发送，目的地址填充为对端的以太网的 MAC 地址
我们来看一下 PADT 报文几个域的填充情况，版本域和类型域不变固定填充
0x01，代码域填充 0xA7，会话 ID 是那个需要被终止的进程，报文中不需要
携带任何标记。当收到 PADT 的时候，不允许再使用当前这个进程发送 PPP
数据流量。在收到或发送 PADT 后甚至正常的 PPP 终止报文也不能被发送。
例如：PADT 数据报文
00 B0 D0 BC AB 75 00 10 A4 97 C1 D9 88 63 11 A7 01 6B 00 00
这个报文中不含有任何标记，而且下划线部分为所需终止的会话进行 ID。
这个数据包可以在会话建立起来之后的任何时间由主机或
集中器发出。目的地址为单一的以太网地址。
ETHER_TYPE值为0x8863，码值为0xa7，SESSION-ID
为要终止的会话的SESSION-ID。不要求有TAG。
PADT报文
一旦 PPPOE 进入到会话阶段，则 PPP 的数据报文就会被填充在 PPPOE 的净
载荷中被传送，这时两者所发送的所有以太网包均是单目地址。PPPOE 会话
阶段以太网帧的协议域填充为 0x8864，代码域填充 0x00，整个会话的过程就
是 PPP 的会话过程，但在 PPPOE 数据域内的 PPP 数据帧是从协议域开始的。
例如：PPPOE 会话阶段的数据报文
00 10 A4 97 C1 D9 00 B0 D0 BC AB 75 88 64 11 00 01 6B 00 14 C0 21 01 00 00 12
01 04 05 DC 03 04 C0 23 05 06 00 00 4E 3D
我们可以看到下划线部分为 PPP 的数据报文（0xC021 表示 LCP 协商阶段，且
为代码域为 0x01 表示是 Config-Request 报文）。
PPP净载荷
目的地址
目的地址 源地址
源地址
帧类型=0x8864 版本=0x1类型=0x1 代码=0x00
会话ID=0x1234 长度=0x????
PPP协议ID=0xC021
PPPOE协议数据包中承载PPP的LCP报文
一旦PPPOE会话建立起来之后，主机与接入器之间就开始依据
PPP协议传送PPP数据，所有的以太网帧都是单一地址的。此时，
ETHER_TYPE值为0x8864，码值为0x00，SESSION-ID在整个
会话过程中保持不变。PPPOE有效负载域里包含一个PPP数据
包。
会话阶段的PPPOE数据报文格式
Netxray 是一个抓包软件，它可以捕获达到本 PC 或从本 PC 发出去的数据包。
这里给出了用该软件捕获的 PPPOE 过程的数据包。
该报文的目的地址是广播地址，对于 PPPOE 来说，它肯定是处于发现阶段的
PADI 报文。从后面的 88 63 和 09 也可以确定这一点。
Net XRayNet XRay抓包结果分析抓包结果分析11
Net XRayNet XRay抓包结果分析抓包结果分析22
Net XRayNet XRay抓包结果分析抓包结果分析33
Net XRayNet XRay抓包结果分析抓包结果分析44
Net XRayNet XRay抓包结果分析抓包结果分析55
Net XRayNet XRay抓包结果分析抓包结果分析66
Net XRayNet XRay抓包结果分析抓包结果分析77
小节
PPPOE协议包括PPPOE的发现阶段和PPPOE的会话阶段
PPPOE的数据报文是被承载在以太网的数据域中进行传送的
PPPOE的发现阶段会遇到PADI、PADO、PADR和PADS这四种报文
PPPOE中的PADT报文是用来终止一条会话的
PPPOE在发现阶段时，以太网协议域的值为0x8863
PPPOE在会话阶段时，以太网协议域的值为0x8864
附录 缩略词表
AAA Authentication Authorization
Accounting
验证、授权、计费
BNCP Bridging Network Control Protocol 桥接网络控制协议
BNP Bridging Network Protocol 桥接网络协议
CHAP Challenge-Handshake Authentication
Protocol
验证请求握手协议
CHAP Challenge Handshake Authentication
Protocol
挑战握手验证协议
CRC Cyclic Redundancy Check 循环校验码
DSAP Destination Service Access Point 目的业务接入点
FCS Frame Check Sequence 帧检查序列
IPCP Internet Protocol Control Protocol IP控制协议
IPX Internet Protocol eXchange protocol IP交换协议
IPXCP Internet Protocol eXchange Control
Protocol
IP交换控制协议
LCP Link Control Protocol 链路控制协议
MRU Maximum Receive Unit 最大接收单元
NAS Network Access Server 网络接入服务器
NCP Network Control Protocol 网络控制协议
PADI PPPoE Active Discovery Initiation PPPoE主动发现初始化包
PADO PPPoE Active Discovery Offer PPPoE主动发现响应包
PADR PPPoE Active Discovery Request PPPoE主动发现请求包
PADS PPPoE Active Discovery
Session-confirmation
PPPoE主动发现会话证实
包
PADT PPPoE Active Discovery Terminate PPPoE主动发现终结包
PAP Password Authentication Protocol 密码验证协议
PAP Password Authentication Protocol 口令验证协议
PPP Point-To-Point Protocol 点到点协议
PPPoA PPP over ATM 在ATM上传输PPP协议
PPPoE PPP over Ethernet 在以太上传输PPP协议
SSAP Source Service Access Point 起源业务接入点
