PPPoE
协议
离婚协议模板下载合伙人协议 下载渠道分销协议免费下载敬业协议下载授课协议下载
PPP & PPPoE协议
larkguo@gmail.com
2007-5-26
目录
1 PPP协议 ..................................................................................................................................... 3
1.1 简介............................................................................................................................. 3
1.2 连接............................................................................................................................. 4
1.3 格式............................................................................................................................. 4
1.3.1 LCP....................................................................................................................... 5
1.3.1.1 Configure-Request ................................................................................. 7
1.3.1.2 Configure-Ack ......................................................................................... 8
1.3.1.3 Configure-Nak ......................................................................................... 9
1.3.1.4 Configure-Reject ................................................................................. 10
1.3.1.5 Terminate-Request and Terminate-Ack ........................................... 10
1.3.1.6 Code-Reject ........................................................................................... 11
1.3.1.7 Protocol-Reject ................................................................................... 12
1.3.1.8 Echo-Request and Echo-Reply ........................................................... 12
1.3.1.9 Discard-Request ................................................................................... 13
1.3.1.10 LCP配置选项 ........................................................................................ 14
1.3.2 PAP..................................................................................................................... 20
1.3.3 CHAP ................................................................................................................... 21
1.3.4 IPCP ................................................................................................................... 22
1.3.4.1 IPCP Configuration Options ............................................................. 23
1.4 过程........................................................................................................................... 23
1.4.1 链路建立 ........................................................................................................... 24
1.4.1.1 阶段1 LCP负责创建链路 .................................................................... 24
1.4.1.2 阶段2用户验证 .................................................................................... 24
1.4.1.3 阶段3调用网络层协议 ........................................................................ 26
1.4.2 终止连接 ........................................................................................................... 26 1.5 选项协商自动机 ....................................................................................................... 26
1.5.1 状态迁移图 ....................................................................................................... 27
1.5.2 状态 ................................................................................................................... 29
1.5.3 事件 ................................................................................................................... 30
1.5.4 动作 ................................................................................................................... 32
1
1.5.5 环躲避(循环避免) ....................................................................................... 34
1.5.6 计数器和定时器 ............................................................................................... 34 1.6 实例........................................................................................................................... 35
1.6.1 PPP Example ..................................................................................................... 35
1.6.2 Negotiations with an ISP ........................................................................... 36
1.6.3 配置 ................................................................................................................... 40
2 PPPPoE协议 ............................................................................................................................. 41
2.1 简介........................................................................................................................... 41 2.2 连接........................................................................................................................... 41 2.3 格式........................................................................................................................... 43 2.4 过程........................................................................................................................... 45
2.4.1 发现阶段 ........................................................................................................... 45
2.4.1.1 PADI ......................................................................................................... 46
2.4.1.2 PADO ......................................................................................................... 47
2.4.1.3 PADR ......................................................................................................... 48
2.4.1.4 PADS ......................................................................................................... 48
2.4.1.5 PADT ......................................................................................................... 49
2.4.2 会话阶段 ........................................................................................................... 50
2.4.3 PPPOE的LCP配置选项 .................................................................................... 51
2.4.4 其它 ................................................................................................................... 51 2.5 实例........................................................................................................................... 51
2.5.1 例1.................................................................................................................... 51
2.5.2 例2.................................................................................................................... 51
2.5.3 例3.................................................................................................................... 52
3 附录 .......................................................................................................................................... 53
3.1 名词解释................................................................................................................... 53
2
1 PPP协议
1.1 简介
PPP(Point-to-Point Protocol点到点协议)是为在同等单元之间传输数据包这样的简单链路设计的链路层协议。PPP协议将IP，IPX和NETBEUI包封装在PP桢内通过点对点的链路发送。这种链路提供全双工操作，并按照顺序传递数据包。
设计目的主要是用来通过拨号或专线方式建立点对点连接发送数据，使其成为各种主机、网桥和路由器之间简单连接的一种共通的解决
方案
气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载
。PPP协议主要应用于连接拨号用户和NAS。
3
1.2 连接
1.3 格式
P帧格式和HDLC帧格式相似， PPP帧的前3个字段和最后两个字段与HDLC的格式是一样的，二者主要区别:PPP是面向字符的，而HDLC是面向位的。
, 标志字段F为0x7E(0x表示7E)
, 地址字段A和控制字段C都是固定不变的，分别为0xFF、0x03。
, 与HDLC不同的是多了2个字节的协议字段。协议字段不同，后面的信息字段类型就不同。
协议字段 说明
0x0021 信息字段是IP数据报
0xC021 信息字段是链路控制数据LCP
0x8021 信息字段是网络控制数据NCP
0xC023 信息字段是安全性认证PAP
0xC025 信息字段是LQR
4
0xC223 信息字段是安全性认证CHAP
, 信息字段中出现和标志字段一样的比特0x7E时，就必须采取一些措施。
因PPP协议是面向字符型的，所以它不能采用HDLC所使用的零比特插入法，而是使
用一种特殊的字符填充。
具体的做法是将信息字段中出现的每一个0x7E字节转变成2字节序列(0x7D，0x5E)。
若信息字段中出现一个0x7D的字节，则将其转变成2字节序列(0x7D，0x5D)。
若信息字段中出现ASCII码的控制字符，则在该字符前面要加入一个0x7D字节。
这样做的目的是防止这些表面上的ASCII码控制字符被错误地解释为控制字符。
0x7e -> 0x7d 0x5e
0x7d -> 0x7d 0x5d
character X < 0x20 -> 0x7d 0xYY (0xYY = X + 0x20)
example : 0x03 ->0x7d 0x23
wangyi< >
1.3.1 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(连结控制协议)。
链环控制协议包格式的摘要如下。
域被从左往右传送。
5
编码域
编码域占一个八位字节。当收到一个带有未知域的包时，一个Code-Reject包被传送。
最新的编码域的值由最近公布的",,,,,,,, ,,,,,,,",,,文档说明。
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)
标识符
标识符域是一个八位字节，对匹配请求和回复中有帮助。当带有无效标识符域的包被接收时候，该包将不影响自动机制，被静静的丢弃。
6
长度
长度域是二个八位字节，指出LCP包的长度，包括代码，标识符，长度和数据域。该长度必须不超过连结的MRU。
长度域以外的字节被当作填料而忽略处理。当收到带有无效标识符该包将不影响自动机制，被静静的丢弃。
数据域
数据域是零或多个八位字节，由长度域声明。数据域的格式由代码域决定。 1.3.1.1 Configure-Request
描述
一个执行想要打开一个连接必须传送一个Configure-Request。选项域被填充任何想要的对连结默认的改变。配置选项应该不被包括到默认值中。Configure-Request的接收上，必须传送适当的答复。
下面给出Configure-Request包的格式的摘要。域从左到右传输。
代码
1 为Configure-Request
标识符
只要选项域改变的内容改变，并且只要收到先前请求的有效响应，标识符域必须被改变。对重发来说，标识符可以保持不变。
选项
选项域是长度的变量，并包含零个或多个发送方需要协商的配置选项的列表。全部配置选项总是被同时协商。在下一章中对配置选项的格式有更详细的描写。
例:
7
1.3.1.2 Configure-Ack
描述
如果Configure-Request中收到的每一个配置选项和全部的值都是能接受的，那么该执行必须传送一个Configure-Ack。该确认配置选项必须不被任何途径的重命令或更改。
Configure-Ack的接收中，标识符域必须匹配最后传送的Configure-Request。另外，Configure-Ack中的配置选项必须完全匹配最后传输的Configure-Request。错误包被静静的丢弃。
一个Configure-Ack包格式如下。域从左到右传输。
8
代码
2 为Configure-Ack
标识符
标识符域是引起Configure-Ack的Configure-Request的标识符域的拷贝。 选项
选项域是长度的变量，并包含零个或多个发送方确认的配置选项的列表。全部配置选项总是被同时确认。
1.3.1.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包格式如下。域从左到右传送。
9
代码
3 为Configure-Nak
标识符
标识符域是导致Configure-Nak的Configure-Request的标识符的拷贝。 选项
选项域是长度的变量，包含零到多个没有应答的发送方的配置选项。
全部配置选项总是同时没有应答的。
1.3.1.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的标识符域的拷贝。 选项
选项域是长度的变量，包含零或者多个发送者拒绝的配置选项列表。全部的配置选项总是被同时拒绝的。
1.3.1.5 Terminate-Request and Terminate-Ack
描述
LCP包含Terminate-Request 和 Terminate-Ack代码是为了提供关闭一个连接的机制。
一个执行想要关闭一个连接应该传送一个Terminate-Request。Terminate-Request包应该继续发送，直到收到Terminate-Ack，低层显示已经关闭了，或者已经接收到了充分大的数量，以致peer有确切地理由关闭。
在一个Terminate-Request接收上，必须传送一个Terminate-Ack。
10
接收一个未被引出的Terminate-Ack表示peer在Closed(关闭)或Stopped(停止)状态，或者需要另外再商议。
Terminate-Request 和 Terminate-Ack包格式如下。域从左到右传送。
代码
5 为Terminate-Request;
6 为Terminate-Ack。
标识符
传送过程中，无论何时数据域的内容发生了改变，而且无论何时接收到一个对前一个请求有效的答复，标识符域必须改变，对于重新传送，标识符可以保持不变。
接收过程中，Terminate-Request的标识符域被拷贝到Terminate-Ack包的标识符域。 资料
数据域由零个或多个八位字节，包含发送方使用的未解释的数据。该数据可以由任何二进制值组成。该域的结束可以由长度指出。
1.3.1.6 Code-Reject
描述
一个带有未知代码的LCP包的接收显示peer由一个不同的版本操作。这必须传送一个Code-Reject
报告
软件系统测试报告下载sgs报告如何下载关于路面塌陷情况报告535n,sgs报告怎么下载竣工报告下载
回给未知代码的发送方。
-Reject的接收中，执行应该报告问
题
快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题
并结束连接，既然 一个基本的该版本协议的Code
该情形不像能被自动矫正。
Code-Reject包格式如下。域从左到右传送。
代码
7 为Code-Reject
标识符
对于每次Code-Reject发送，该标识符域必须被改变。
被拒绝的包
被拒绝的包域包含被拒绝的LCP包的拷贝。它由信息域开始，并且不包括任何数据链路层的头或者FCS。被拒绝的包必须被缩短来符合peer指定的MRU。
11
1.3.1.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。
1.3.1.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包格式如下。域从左到右传送。
代码
12
9 为Echo-Request;
10 为Echo-Reply
标识符
传输中，无论何时数据域内容的改变，并且无论何时接收到前一个请求的有效的响应，标识符域必须被改变。对于重新传送标识符可以保持不变。
接收中，Echo-Request的标识符域被拷贝到Echo-Reply包的标识符域。 Magic-Number
Magic-Number域是四个八位字节，对检测处于looped-back条件下的连结有帮助。在该Magic-Number配置选项被成功的协商之前，Magic-Number必须被以零传送。在Magic-Number配置选项中由更详细的说明。
数据
数据域是零或者多个八位字节，包含被发送方使用的未解释的数据。该数据可以由任何二进制值组成。该域的结束由长度指出。
1.3.1.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配置选项中由更详细的说明。
数据
数据域是零或者多个八位字节，包含被发送方使用的未解释的数据。该数据可以由任何二进制值组成。该域的结束由长度指出。
13
1.3.1.10 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应该被传送包括带有适当的长度和数据的想得到的配置选项。
数据
数据域是零个或者更多的八位字节，并且包含配置选项的特殊详细信息。数据域的类型和长度由类型和长度域所决定。
当数据域由长度到扩充超过信息域的结束所指出，整个包被不通知自动机制静静的丢弃。
Common Option Default
Maximum receive unit 1500
14
Authentication protocol None
Protocol field compression Off
Address and control field compression Off
1.3.1.10.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，也不包括任何透明位或字节。
1.3.1.10.2 Authentication-Protocol 描述
一些连结可能想要peer在允许网络层协议包被交换之前鉴别它自己。
该配置选项提供一种使用详细而准确的协议进行鉴定的方法。默认的，不需要鉴定。
一个执行必须不在Configure-Request包中包含多重鉴定协议配置选项。代替的，应该首先尝试配置最值得要的协议。如果协议是Configure-Nak的，那么该执行应该在下一个Configure-Request中尝试下一个最值得要的协定。
该执行发送Configure-Request指出它所期待的来自它的peer的鉴定。如果一个执行发送一个Configure-Ack ，那么它同意进行指定协议的鉴定。一个执行接收一个Configure-Ack应该期待peer用公认协议进行鉴别。
没有必要采用全双工或者将同一个协议用于两个方向。允许每个方向采用不同的协议是极好的。这将，当然，取决于协商的详细协议。
15
Authentication-Protocol配置选项格式如下。域从左到右传送。
类型
3
长度
>=4
Authentication-Protocol
Authentication-Protocol域是两个八位字节，指出想要鉴定的协定。该域的值总是与PPP协议域值一样用于同样的鉴定协议。
Authentication-Protocol域的Up-to-date值在最近的"Assigned Numbers" RFC [2]中被指定。
当前的值被赋值如下:
值(十六进制) 协定
c023 密码证明协议
c223 挑战握手验证协定
数据
数据域是零或多个八位字节，包含作为由详细协议决定了的附加资料。 1.3.1.10.3 Quality-Protocol
描述
一些连结上可能想要决定何时，和间隔多长时间，该连结丢弃数据。该过程被叫做连结质量监测。
该配置选项提供一种用于连结质量监测的使用详细协议的商议方法。默认的，禁止连结质量监测。
该执行发送的Configure-Request指出它希望接收的来自它的peer的监测信息。
如果一个执行发送一个Configure-Ack，那么它同意使用详细协议。一个协议接收一个Configure-Ack应该等待peer发送确认协定。
不必要进行全双工或双方都使用同样的协议的质量监测。最好两端使用不同的可接受的协议。这将，当然，取决于商议的详细的协议。
Quality-Protocol配置选项格式如下。域从左到右传送。
类型
4
长度
>=4
16
Quality-Protocol
Quality-Protocol域是两个八位字节，指出连结想要的质量监测协议。该域的值总是与用于相同的监测协议的PPP协议域值相同。
Quality-Protocol域的Up-to-date值在最近的"Assigned Numbers" RFC [2]中指定。当前值的赋值如下:
值(十六进制) 协定
c025 连结质量报告
数据
数据域是零或者多个八位字节，包含由详细协议决定的附加数据。
1.3.1.10.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
17
唯一的或者随机的好的源被发生的分歧所需要。如果一个唯一的好的源不能被找到，推荐配置选项不能被启动:带有该选项的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是违法的，必须总是没有应答，如果不被彻底拒绝。
1.3.1.10.5 Protocol-Field-Compression (PFC) 描述
该配置选项提供一种PPP协议域的压缩协商方法。默认的，所有执行必须传送带有二个八位字节PPP协议域的数据包。
18
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
1.3.1.10.6 Address-and-Control-Field-Compression (ACFC)
描述
该配置选项提供一种数据链路层地址和控制域压缩的方法。默认的，所有执行必须传送带有地址和控制域的适当的连结帧。
既然这些域通常用于点对点连结有常量，容易压缩。该配置选项被发送来通知peer该执行能接收压缩地址和控制域。
如果当Address-and-Control-Field-Compression未被协商时接收到一个压缩了的包，该执行可以静静的丢弃该包。
当发送任何LCP包时，地址和信息域必须不被压缩。该规则保证明确识别LCP包。
当地址和控制域被压缩时，数据链路层FCS域被在被压缩的包计算，而不是最初的未压缩包。
Address-and-Control-Field-Compression配置选项格式如下。域从左到右传递。
类型
19
8
长度
2
1.3.2 PAP
例:
20
1.3.3 CHAP
21
1.3.4 IPCP
Code. 8 bits.
Code IPCP Packet 01 Configure-request 02 Configure-ack 03 Configure-nak 04 Configure-reject 05 Terminate-request 06 Terminate-ack 07 Code-reject
22
Identifier. 8 bits.
Used to match requests and replies. Length. 16 bits.
Size of the packet including the header. Data. Variable length.
Zero or more bytes of data as indicated by the Length. This field may contain
one or more Options.
1.3.4.1 IPCP Configuration Options
Option. 8 bits.
Option Length Description References 1 IP-Addresses. Deprecated. RFC1332 2 >= 14 IP-Compression-Protocol. RFC1332, RFC3241, RFC
3544 3 6 IP-Address. RFC 1332 4 6 Mobile-IPv4. RFC 2290 129 6 Primary DNS Server Address. RFC 1877 130 6 Primary NBNS Server Address. RFC 1877 131 6 Secondary DNS Server Address. RFC 1877 132 6 Secondary NBNS Server Address. RFC 1877 Length. 8 bits.
Data. Variable length.
1.4 过程
PPP协议中提供了一整套方案来解决链路建立、维护、拆除、上层协议协商、认证等问题。PPP协议包含这样几个部分:
, 链路控制协议LCP(Link Control Protocol)， LCP负责创建，维护或终止一次物理连
接。
, 网络控制协议NCP(Network Control Protocol)，NCP是一族协议，负责解决物理连接
上运行什么网络协议，以及解决上层网络协议发生的问题，如IPCP; , 认证协议，最常用的包括口令验证协议PAP(Password Authentication Protocol)和
23
挑战握手验证协议CHAP(Challenge-Handshake Authentication Protocol)。
1.4.1 链路建立
一个典型的链路建立过程分为三个阶段:创建阶段、认证阶段和网络协商阶段。
为了通过点对点链路建立通信，PPP链路的每一端，必须首先发送LCP packets以便设定和测试数据链路。在链路建立之后，peer才可以被认证。然后，PPP必须发送NCP packets以便选择和设定一个或更多的网络层协议。一旦每个被选择的网络层协议都被设定好了，来自每个网络层协议的datagrams就能在连路上发送了。链路将保持通信设定不变，直到外在的LCP和NCP关闭链路，或者是发生一些外部事件的时候(休止状态的定时器期满或者网络管理员干涉)。
1.4.1.1 阶段1 LCP负责创建链路
当线路处于静止状态时，并不存在物理层的连接。当检测到调制解调器的载波信号，并建立物理层连接后，线路就进入建立状态，这时LCP开始协商一些选项。
PPP使用链路控制协议(LCP)创建，维护或终止一次物理连接。在LCP阶段的初期，将对基本的通讯方式进行选择。链路两端设备通过LCP向对方发送配置信息报文(Configure Packets)。一旦一个配置成功信息包(Configure-Ack packet)被发送且被接收，就完成了交换，进入了LCP开启状态。
LCP协商内容包括除RFC1661中所定义的选项之外，还要考虑PPPOA和PPPOE协议中规定的内容。
应当注意在链路创建阶段，只是对验证协议进行选择，用户验证将在第2阶段实现。 1.4.1.2 阶段2用户验证
LCP协商过后就到了Establish阶段，在这个阶段，客户端会将自己的身份发送给远端的接入服务器。该阶段使用一种安全验证方式避免第三方窃取数据或冒充远程客户接管与客户端的连接。在认证完成之前，禁止从认证阶段前进到网络层协议阶段。如果认证失败，认证者应该跃迁到链路终止阶段。
在这一阶段里，只有链路控制协议、认证协议，和链路质量监视协议的packets是被允许的。在该阶段里接收到的其它的packets必须被静静的丢弃。
24
缺省时，认证不是必要的。如果应用时希望对等实体使用某些认证协议进行认证，这种要求必须在建立连接阶段提出。
应用注意事项:
应用时不能简单的因为超时或缺少回应就认为认证失败。应该允许重传，仅当试图认证的次数超过一定的限制时才进入终止连接阶段。
如果对方拒绝认证，己方有权进入终止连接阶段。
最常用的认证协议有口令验证协议(PAP)和挑战握手验证协议(CHAP)。 1.4.1.2.1 口令验证协议(PAP)
PAP是一种简单的明文验证方式。PAP为两次握手认证，认证过程如下: , 发送用户名同口令到认证方;
, 认证方查看是否有此用户，口令是否正确，然后发送相应的响应。
NAS(网络接入服务器，Network Access Server)要求用户提供用户名和口令，PAP以明文方式返回用户信息。很明显，这种验证方式的安全性较差，第三方可以很容易的获取被传送的用户名和口令，并利用这些信息与NAS建立连接获取NAS提供的所有资源。所以，一旦用户密码被第三方窃取，PAP无法提供避免受到第三方攻击的保障措施。 1.4.1.2.2 挑战握手验证协议(CHAP)
CHAP是一种加密的验证方式，能够避免建立连接时传送用户的真实密码，CHAP为三次握手认证。
, NAS向远程用户发送一个挑战口令(challenge)，其中包括会话ID和一个任意生成
的挑战字符串(arbitrary challengestring);
用户名和, 远程客户必须使用MD5单向哈希算法(one-way hashing algorithm)返回
加密的挑战口令，会话ID以及用户口令，其中用户名以非哈希方式发送;
, 认证方用自己保存的口令字及随机报文用MD5算法加密，比较二者的密文，根据比
较结果返回响应的响应。
CHAP对PAP进行了改进，不再直接通过链路发送明文口令，而是使用挑战口令以哈希算法对口令进行加密。因为服务器端存有客户的明文口令，所以服务器可以重复客户端进行的操作，并将结果与用户返回的口令进行对照。
CHAP为每一次验证任意生成一个挑战字符串来防止受到再现攻击(replay attack)。在整个连接过程中，CHAP将不定时的向客户端重复发送挑战口令，从而避免第3方冒充远程客户(remote client impersonation)进行攻击。
25
1.4.1.3 阶段3调用网络层协议
认证成功即进行Network阶段协商(NCP)，选定PPP链路之上的高层协议，在IP接入中主要是IPCP协商(如IP地址和DNS地址的协商等)。
任何阶段的协商失败都将导致链路的拆除;协商成功，则链路建立成功，可以开始传输网络层数据报文。
1.4.2 终止连接
P,,连接可以随时终止。原因可能是载波丢失、认证失败、连接质量失败、超时计数器溢出，或者网络管理员关闭连接。
L,,通过交换连接终止包来终止连接。当连接正在被终止的时候，,,,会通知网络层以便它采取相应的动作。
在交换过终止请求包(Terminate packets)后，将通知物理层断开以便使连接真正终止，尤其是在认证失败的时侯。
Terminate-Request(终止-要求)的发送者，在收到Terminate-Ack(终止-允许)后，或者在重置计数器期满后，应该断开连接。收到Terminate-Request的一方，应该等待peer去切断，在发出Terminate-Request后，至少也要经过一个Restart time(重置时间)，才允许断开。PPP应该前进到连结死亡阶段。 在此阶段所有接收到的非,,,数据包都将被静默丢弃。
应用注意事项:
LCP关闭连结就足够了，不需要每一个NCP发送一个Terminate packets。相反，一个NCP关闭却不足以引起PPP连结的终止，即使那个NCP是当前唯一一个处于Opened状态的NCP。 1.5 选项协商自动机
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确实有着不同的功能。然而他们总是引起相同的转换。
26
1.5.1 状态迁移图
全部的状态转换如下表。状态在水平轴，事件在垂直轴。状态转换和动作备表示成:动作/新状态的形式。多个动作用逗号分隔，无先后顺序。状态后面跟的那个字母是说明性的脚
27
注。短划线('-')代表无效的转换
那些其中运行着重置定时器的状态，是可以由存在的TO事件确认的。只有 Send-Configure-Request，Send-Terminate-Request和Zero-Restart-Count动作才启动或者重新启动重置定时器。当从任意一个定时器运行的状态转换到一个定时器不运行的状态时，重置定时器(Restart timer)停止。
根据消息通过体系机构而不是信号通知体系机构，人们定义了事件和动作。如果希望一
28
个动作去控制特定的信号(如DTR)，那就可能需要额外的动作。
[p] 被动选项;见Stopped状态讨论。
[r] 重启选项;见Open事件讨论。
[x] 交叉连接;见RCA事件讨论。
1.5.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- 事件。
这个选项对于专用
电路
模拟电路李宁答案12数字电路仿真实验电路与电子学第1章单片机复位电路图组合逻辑电路课后答案
或者没有可用的状态信号的电路有用，但禁止用于交换电路。
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
29
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。
1.5.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命令。这表明
30
新的值将被协商。既然这不是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时，该事件发
31
生。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没有回应。
1.5.4 动作
自动机中的动作有事件引起。典型的，动作表明了packets的传输，和/或Restart timer的启动和停止。
Illegal-Event (-):不合法的事件
该动作指出一个在正常执行的自动机中不可能出现的事件。执行有一个内在的错误，应该把它报告并记录下来。没有转换被执行，执行不应该reset or freeze(重新安排或冻结)。
This-Layer-Up(tlu)
动作给自动进入打开阶段的上边的层做指示。
典型的，该动作被LCP用于对一个NCP发送向上的事件信号，或者连结质量协议，或者可以被一个NCP用于显示该连结可用于它的网络层往来。
This-Layer-Down(tld)
该动作给自动留下打开的阶段的上边的层做指示。
典型地，该动作被LCP用于向一个NCP发送向下的事件，证实协议，或者可以被一个NCP用于显示该连结对它的网络层传输不再可用。
32
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)
33
一个Terminate-Ack包被传送。
这确认Terminate-Request的包的接收，或者以别的方式对于自动同步起作用。
Send-Code-Reject(scj)
一个Code-Reject包被传送。
这表示未知的种类的包的接收。
Send-Echo-Reply (ser)
一个Echo-Reply包被传送。
这确认一个Echo-Request包的接收。
1.5.5 环躲避(循环避免)
协议做避开协商成环状的配置选项的适当尝试。
不过，协议不保证环将不发生。
和任何协商一样，有可能来设置2个PPP由不收敛的矛盾的方法来执行。
同样，也有可能配置收敛的，重要的时间这样去做的方法。
设备应该考虑这些，并且应该满足环侦测机制或更高水平的超时。
1.5.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不会应答前的，没有接收到一
34
个有效的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)次传输。
1.6 实例
1.6.1 PPP Example
35
1.6.2 Negotiations with an ISP
36
37
38
39
1.6.3 配置
路由器Router1和Router2的S0口均封装PPP协议，采用CHAP做认证，在Router1中应建立一个用户，以对端路由器主机名作为用户名，即用户名应为router2。同时在Router2中应建立一个用户，以对端路由器主机名作为用户名，即用户名应为router1。所建的这两用户的password必须相同。
设置如下:
Router1:
hostname router1
username router2 password xxx
interface Serial0
ip address 192.200.10.1 255.255.255.0 clockrate 1000000
ppp authentication chap
Router2:
hostname router2
username router1 password xxx
40
interface Serial0
ip address 192.200.10.2 255.255.255.0 ppp authentication chap
2 PPPPoE协议
2.1 简介
PPPoE(PPP over Ethernet)是在以太网络中转播PPP帧信息的技术。通常PPP(point-to-point protocol)是用来通过电话线路及ISDN拨号接驳到ISP时使用。该协议具有用户认证及通知IP地址的功能。在ADSL中，PPPoE用来接驳ADSL Modem与家庭中的个人电脑或者路由器。
PPPOE在标准PPP报文的前面加上以太网的报头，使得PPPOE提供通过简单桥接接入设备连接远端接入设备，并可以利用以太网的共享性连接多个用户主机，在这个模型下，每个用户主机利用自身的ppp堆栈，用户使用熟悉的界面。接入控制，计费等都可以针对每个用户来进行。
2.2 连接
41
42
2.3 格式
ETHER_TYPE 说明
0x8863 Discovery Stage，PPPOE发现阶段。
0x8864 PPP Session Stage，PPPOE的会话阶段。
1. PPPOE数据报文最开始的4位为版本域，协议中给出了明确的规定，这个域的内容填充
0x01。
2. 紧接在版本域后的4位是类型域，协议中同样规定，这个域的内容填充为0x01。 3. 代码域占用1个字节，对于PPPOE 的不同阶段这个域内的内容也是不一样的，在这里没
有用表格的形式将所有代码列出。
CODE类型 说明
0x00 PPP Session Stage
0x09 PPPOE Active Discovery Initiation (PADI) packet
0x07 PPPOE Active Discovery Offer (PADO) packet
0x19 PPPOE Active Discovery Request (PADR) packet
0x65 PPPOE Active Discovery Session-confirmation
4. 会话ID点用2个字节，当访问集中器还未分配唯一的会话ID给用户主机的话，则该域
内的内容必须填充为0x0000，一旦主机获取了会话ID后，那么在后续的所有报文中该
域必须填充那个唯一的会话ID值。
5. 长度域为2个字节，用来指示PPPOE数据报文中净载荷的长度。
43
6. 数据域，有时也称之为净载荷域，在PPPOE的不同阶段该域内的数据内容会有很大的不
同。在PPPOE的发现阶段时，该域内会填充一些Tag(标记);而在PPPOE的会话阶段，
该域则携带的是PPP的报文。对于发现阶段的PPPOE数据报文而言，它的净载荷可能包
含零个或多个Tag(标记)，实际上这些标记的意义非常类似于PPP配置参数选项，它同
样也是要经过协商的。对于PPPOE协议而言，没有像PPP的配置参数选项那样定义了很
多细节，而只是一个初略的定义，因此在实际当中实现这个过程会依据不同厂商的设备
有不同。首先还是让我们看一下承载在PPPOE报文数据域中的标记封装格式:
从上图中可以看出，标记的封装格式采用的是大家所熟知的TLV结构，也即是(类型+长度+数据)。
1. 标记的长度域为2个字节，它用来指明标记数据域的长度。
2. 标记的数据域中用来放置不同类型标记所对应的相关数据。
3. 标记的类型域为2个字节，下表列出了各种标记类型的含义:
标记类型 标记说明
0x0000 表示PPPOE报文数据域中一串标记的结束，为了保证版本的兼容性而保留，
在有些报文中有应用。
0x0101 服务名，主要用来表明网络侧所能提供给用户的一些服务。
0x0102 访问集中器名，当用户侧接收到了AC的回应的PADO报文时，就可获从所携
带的标记中获知访问集中器的名字，而且还可以据此来选择相应的访问集
中器。
0x0103 主机唯一标识，类似于PPP数据报文中的标识域，主要是用来匹配发送和
接收端的，因为对于广播式的网络中会同时存在很多个PPPOE的数据报文。
0x0104 AC-Cookies，主要被用来防止恶意性DOS功击。
0x0105 销售商的标识符。
0x0110 中继会话ID，对于PPPOE的数据报文也同样可以像DHCP报文一样被中断到
另外的AC上终结，这个字段则是用来维护另一个连接的。
0x0201 服务名错误，当请求的服务名不被对端所接受时，会在响应的报文中携带
这个标记。
0x0202 访问集中器名出错。
0x0203 一般性错误。
44
2.4 过程
PPPoE建立过程可以分为Discovery阶段和PPP Session阶段。Discovery阶段是一个无状态的阶段，该阶段主要是选择接入服务器，确定所要建立的PPP会话标识符Session ID，同时获得对方点到点的连接信息;PPP Session 阶段又可分为LCP 协商阶段认证阶段和IPCP 阶段。
2.4.1 发现阶段
PPPOE的发现阶段可分为四步，其实这个过程也是PPPOE四种数据报文的交换的一个过
45
程。当完成这四步后，用户主机与访问集中器双方就能获知对方的MAC地址和唯一的会话ID号，从而进入到下一个阶段(PPPOE的会话阶段)。实际上双方在互相知道了对方的MAC地址后，就已经在广播式的网络上确定了一一的对应关系，为了保证这个连接的有效性，同时使PPPOE协议能更加灵活的运用，因此还加入了会话ID字段，通过这两个条件就可完成确定双方点对点的关系。
, PPPOE的数据报文是被承载在以太网的数据域中进行传送的
, PPPOE的发现阶段会遇到PADI、PADO、PADR和PADS这四种报文
, PPPOE中的PADT报文是用来终止一条会话的
, PPPOE在发现阶段时，以太网协议域的值为0x8863
PoE协议发现过程和DHCP协议过程相似，都是分两部:发现和请求。PPPoE client发现PPPoE server(PPP协议支持的设备)，DHCP client发现DHCP server;PPPoE client请求会话ID，DHCP client 请求IP.
2.4.1.1 PADI
PPPOE发现阶段的第一步，也即是由用户侧首先发送这样一个报文。用户主机是以广播的方式发送这个报文，所以该报文所对应的以太网帧的目的地址域应填充为全1，而源地址域填充用户主机的MAC地址。广播包可能会被多个访问集中器接收到，后面会讲到对于接收到PADI报文的访问集中器会使用PADO报文来回应用户主机。
我们来看一下PADI报文中几个域的填充情况，前面已强调过版本域和类型域固定填充0x01，因为两个域各占4位，所以合并为1个字节后应为0x11。PADI报文的代码域填充0x09，会话ID填充0x0000。PADI报文必须含一个由用户侧请求的正确服务名标记，当然还可能携带一些其它的标记，而一个完整的PADI报文(包括PPPOE头)不能超过1484个字节，以便能留下足够的空间给中继代理增加一个中继的会话ID标记。
46
例:PADI 数据报文
这个报文中包括两个标记:一个是主机的只唯一标识，另一个则是服务名标记，从上面这个报文中可以看出服务名没有具体实际的内容，说明对于用户主机可以接受任何由访问集中器所提供的服务。
2.4.1.2 PADO
PPPOE发现阶段的第二步，也即是由访问集中器回应各用户主机发送的PADI报文，此时该报文所对应的以太网帧的源地址填充访问集中器的MAC地址，而目的地址则填充从PADI
47
中所获取的用户主机的MAC地址。
我们来看一下PADO报文几个域的填充情况，版本域和类型域不变固定填充0x01，代码域填充0x07，会话ID填充0x0000。PADO报文中必须包含一个访问集中器名这个标记，同时还要包含对PADI报文中服务名标记的确认标记和对其它标记的一些确认标记。这个过程有点类似于PPP协议中链路建立过程中的Config-Ack报文，当然如果用户主机所申请的服务访问集中器不支持的话，则访问集中器就不会回应PADO报文。
例:PADO 数据报文
这个报文中包括4个标记，在PADI所提供的标记的基础上又增加了两个标记，一个是访问集中器名，下划线部分即表示访问集中器名(MD5500)，而且还包含一个标记结束标记。
2.4.1.3 PADR
PPPOE发现阶段的第三步，也即是由用户主机向访问服务器发送单播的请求报文。当用户主机收到PADO报文后，会从这些报文中挑选一个访问集中器作为后续会话的对象。由于用户主机在收到PADO报文后，就获知了访问集中器的MAC地址，因此PADR报文所以应的以太网帧的源地址填充用户主机的MAC地址，而以太网的目的地址填充为访问集中器的MAC地址。 我们来看一下PADR报文几个域的填充情况，版本域和类型域不变固定填充0x01，代码域填充0x19，会话ID域填充0x0000。此时PADR报文必须准确地包含一个服务名的标记，指示用户主机申请的服务和其它的标记类型。
例:PADR 数据报文
当收到访问集中器的PADO报文后，用户主机会发送PADR报文，该报文所含的标记域与PADI报文中的一致，但些时用户主机已获知了访问集中器名。
2.4.1.4 PADS
PPPOE发现阶段的第四步，也即是最后一步，此时访问集中器当收到PADR报文时，就准备进入开始一个PPP的会话了，而此时访问集中器会为在这个会话分配一个唯一的会话进程
48
ID，并在发送给主机的PADS报文中携带上这个会话ID。当然如果访问集中器不满足用户所申请的服务的话，则会向用户发送一个PADS报文，而其中携带一个服务名错误的标记，而且此时该PADS报文中的会话ID填充0x0000。
我们来看一下PADS报文几个域的填充情况，版本域和类型域不变固定填充0x01，代码域填充0x65，会话ID必须设为给这个PPPOE进程所分配的唯一值。
例:PADS 数据报文
其中下划线部分为访问集中器给这个PPPOE会话分配的唯一会话ID。
2.4.1.5 PADT
PADT报文可能在会话进行开始之后的任意时间内被发送，主要是用来终止一个PPPOE会话的。它可以由主机或访问集中器发送，目的地址填充为对端的以太网的MAC地址 我们来看一下PADT报文几个域的填充情况，版本域和类型域不变固定填充0x01，代码域填充0xA7，会话ID是那个需要被终止的进程，报文中不需要携带任何标记。当收到PADT的时候，不允许再使用当前这个进程发送PPP数据流量。在收到或发送PADT后甚至正常的PPP终止报文也不能被发送。
例:PADT 数据报文
这个报文中不含有任何标记，而且下划线部分为所需终止的会话进行ID。
49
2.4.2 会话阶段
, PPPOE在会话阶段时，以太网协议域的值为0x8864
一旦PPPOE进入到会话阶段，则PPP的数据报文就会被填充在PPPOE的净载荷中被传送，这时两者所发送的所有以太网包均是单播的，PPPOE会话的 SESSION_ID一定不能改变，并且必须是发现阶段分配的值。
PPPOE会话阶段以太网帧的协议域填充为0x8864，代码域填充0x00，整个会话的过程就是PPP的会话过程，但在PPPOE数据域内的PPP数据帧是从协议域开始的。
例:PPPOE会话阶段的数据报文
下划线部分为PPP的数据报文(0xC021表示LCP协商阶段，且为代码域为0x01表示是Config-Request报文)。
50
2.4.3 PPPOE的LCP配置选项
PPP over Ethernet(RFC2516)建议进行魔数选项协商，不建议进行协议域压缩选项(PFC)协商。
实现中必须不请求进行任何下面的选项协商，并且必须拒绝这样选项协商的请求:Field Check Sequence (FCS) Alternatives, Address-and-Control-Field-Compression (ACFC), Asynchronous-Control-Character-Map (ACCM) MRU必须不能大于1492。
2.4.4 其它
建议接入集中器偶尔向主机发送Echo_Request报文，来决定会话的状态。否则，如果主机没有发送Terminate_Request报文就终止了会话，接入集中器将会不能决定会话已经终止了。
当LCP终止，主机和接入集中器必须停止使用这个PPPOE会话。如果主机希望开始另一个PPP会话，它必须返回到PPPOE的发现阶段。
2.5 实例
2.5.1 例1
2.5.2 例2
POE: Sending PADI packet for PPP
POE: ENET Received PADO packet
POE: Sending PADR packet for PPP
POE: ENET Received PADS packet
POE: PPP Session ID = 0x1e12 is open
PPP: LCP We processed peer's requests:
51
PPP: max-recv-unit, mru 1492 (ack)
PPP: auth-type, auth (ack)
PPP: magic-num, 0x41d8799 (ack)
PPP: LCP Peer acknowledged our requests:
PPP: mru 1492
PPP: magic-num, 0xea27fe02
PPP: LCP We processed peer's requests:
PPP: max-recv-unit, mru 1492 (ack)
PPP: auth-type, auth (ack)
PPP: magic-num, 0xdeeb76cb (ack)
PPP: LCP Peer acknowledged our requests:
PPP: mru 1492
PPP: magic-num, 0xb9aebba6
PPP: PAP authentication success reported by peer
IPCP: Resettings options: ip (0.0.0.0), dns (0.0.0.0, 0.0.0.0)
IPCP: IPCP We acknowledged peer's requests:
IPCP: IP-Addr: peer-addr 216.117.66.1
IPCP: Peer Nak'd our addr (0.0.0.0) with addr (216.117.108.2); accepting peer's address preference
IPCP: Peer Nak'd our primary DNS (0.0.0.0) with (209.172.192.2); accepting peer's primary DNS
address
IPCP: Peer Nak'd our secondary DNS (0.0.0.0) with (209.172.194.2); accepting peer's secondary
DNS address
IPCP: IPCP Peer acknowledged our request:
IPCP: IP-Addr: local-addr 216.117.108.2
IPCP: Primary DNS: 209.172.192.2
IPCP: Secondary DNS: 209.172.194.2
IPCP: IP up, local 216.117.108.2, remote 216.117.66.1 2.5.3 例3
00:56:05 |System |Manual Reboot from Web User Interface 00:56:05 |System |modem rebooting...
00:56:18 |System |=============== SYSTEM UP =============== 00:56:18 |System |Current Mode: PPP on the modem (Public IP for LAN device)
00:56:19 |DSL |DataPump Version 01.01.00.00
00:56:19 |DSL |State: WAITING
00:56:20 |Ethernet |Link 1 Up - 10Base-T Half Duplex 00:56:31 |DSL |State: INITIALIZING
00:56:36 |DHCP Server |Address 192.168.1.64 given out to 00:08:02:0b:93:73
00:56:38 |DSL |HYBRID 1
00:56:38 |DSL |Link up 1 US 160 DS 1536 (FAST:G.dmt) 00:56:46 |PPPoE |tx PADI, id: 0000, ac: (NULL), sn: (NULL) 00:56:46 |PPPoE |rx AC Name: 62031020042800-ipltinho03w 00:56:46 |PPPoE |tx PADR, id: 0000, ac: (NULL), sn: (NULL)
52
00:56:46 |PPPoE |rx PADS id: 2BAF
00:56:46 |PPP |LCP neg PAP
00:56:46 |PPP |LCP up
00:56:48 |PPP |IPCP nak option: 3
00:56:48 |PPP |IPCP nak option: 129
00:56:48 |PPP |IPCP nak option: 131
00:56:48 |PPP |IPCP up ip: 68.251.190.179, gw: 68.251.191.254, dns: 67.36.128.26, 206.141.192.60
00:56:57 |SNTP Client |Updated time from Primary server 132.163.4.103 00:57:06 |DHCP Server |Smarttimeout invoked, lease timeout 00:57:06 |PPP |LCP down
00:57:06 |PPP |IPCP down
00:57:09 |PPPoE |rx PADT id: 2BAF
00:57:09 |PPPoE |tx PADI, id: 0000, ac: (NULL), sn: (NULL) 00:57:09 |PPPoE |rx AC Name: 62031020042800-ipltinho03w 00:57:09 |PPPoE |tx PADR, id: 0000, ac: (NULL), sn: (NULL) 00:57:09 |PPPoE |rx PADS id: 2BC7
00:57:09 |PPP |LCP neg PAP
00:57:09 |PPP |LCP up
00:57:10 |PPP |IPCP nak option: 3
00:57:10 |PPP |IPCP nak option: 129
00:57:10 |PPP |IPCP nak option: 131
00:57:10 |PPP |IPCP up ip: 68.251.182.230, gw: 68.251.183.254, dns: 67.36.128.26, 206.141.192.60
00:57:39 |DHCP Server |Address 68.251.182.230 given out to 00:08:02:0b:93:73
01:25:40 |PPP |Max echo misses
01:25:40 |PPP |LCP down
01:25:40 |PPP |IPCP down
01:25:58 |PPPoE |tx PADT, id: 2BC7, ac: (NULL), sn: (NULL) 01:30:36 |DHCP Server |Last DHCP Server message repeated 5 times. 01:30:36 |DHCP Server |Address 192.168.1.64 given out to 00:08:02:0b:93:73
02:04:23 |User |lanadmin: Logged in to 192.168.1.64 02:04:24 |System |Manual Reboot from Web User Interface 02:04:24 |System |modem rebooting...
3 附录
3.1 名词解释
PPP Point to Point Protocol 点到点协议
PPPoE PPP over Ethernet 以太网上的PPP协议
ISP Internet Service Provider Internet服务提供商
NAS Network Access Server 网络接入服务器
PAP Password Authentication Protocol 口令验证协议
53
CHAP Challenge Handshake Authentication 挑战握手验证协议
Protocol
LCP Link Control Protocol 链路控制协议 NCP Network Control Protocol 网络层控制协议 IPNP Internet Protocol Control Protocol IP控制协定 PADI PPPOE Active Discovery Initiation 主机广播一个发起分组 PADO PPPOE Active Discovery Offer 一个或多个接入集中器发
送给予分组 PADR PPPOE Active Discovery Request 主机发送单播会话请求分
组
PADS PPPOE Active Discovery 选择的接入集中器发送一
Session-confirmation 个确认分组 PADT PPPOE Active Discovery Terminate PPPoE有效发现终止包
54
浙公网安备 33021202002483