PPPOE 详解

朴灿烈づ我的快乐病毒、 2022-04-11 20:58 1902阅读 0赞

# 1 概述 #

(1) PPPoE（ Point to Point Protocol over Ethernet ，基于以太网的点对点协议）的工作流程包含发现（ Discovery） 和会话（ Session） 两个阶段，发现阶段是无状态的，目的是获得PPPoE 终端（在局端的ADSL设备上）的以太网MAC 地址，并建立一个惟一的PPPoE SESSION-ID。发现阶段结束后，就进入标准的PPP会话阶段。

(2) 当一个主机想开始一个PPPoE会话，它必须首先进行发现阶段，以识别局端的以太网MAC地址，并建立一个PPPoE SESSION-ID。在发现阶段，基于网络的拓扑，主机可以发现多个接入集中器，然后允许用户选择一个。当发现阶段成功完成，主机和选择的接入集中器都有了他们在以太网上建立PPP连接的信息。直到PPP会话建立，发现阶段一直保持无状态的Client/Server（客户/服务器）模式。一旦PPP会话建立，主机和接入集中器都必须为PPP虚接口分配资源。

(3) PPPOE可以防止ARP攻击。PPPOE能真正防止ARP的原因不在于，PPPOE接口IP和以太网接口IP不同，也不是通讯建立后不再用MAC等原因。而是因为PPPOE根本就没用的ARP协议，尽管它是用以太帧封装的，但它获得服务器MAC的方法不是用ARP协议，而是通过PADI包,所以它可以防止ARP攻击。

# 2 PPPOE 报文 #

(1) PPP帧格式如下

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70][]

看到总共多了8个字节，其中首尾字节都是帧的起始和结束标志位，A表示地址，C表示控制。

协议的两个字节，表示后面信息部分的数据协议是什么，包括：

<table> 
 <tbody> 
 <tr> 
 <td> 数值 </td> 
 <td> 说明 </td> 
 </tr> 
 <tr> 
 <td> 0x0021 </td> 
 <td> 信息字段是IP数据报。 </td> 
 </tr> 
 <tr> 
 <td> 0xC021 </td> 
 <td> 信息字段是链路控制数据LCP。 </td> 
 </tr> 
 <tr> 
 <td> 0x8021 </td> 
 <td> 信息字段是网络控制数据NCP。 </td> 
 </tr> 
 <tr> 
 <td> 0xC023 </td> 
 <td> 信息字段是安全性认证PAP。 </td> 
 </tr> 
 <tr> 
 <td> 0xC025 </td> 
 <td> 信息字段是LQR。 </td> 
 </tr> 
 <tr> 
 <td> 0xC223 </td> 
 <td> 信息字段是安全性认证CHAP。 </td> 
 </tr> 
 </tbody> 
</table>

(2) PPPoE的报文就是在PPP的报文前面再加上PPPOE头和以太网的报头，使得PPPoE可以通过简单桥接设备连入远端接入设备。

PPPOE字段如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 1][]

各个字段解释如下：

<table> 
 <tbody> 
 <tr> 
 <td> 字段 </td> 
 <td> 说明 </td> 
 </tr> 
 <tr> 
 <td> Destination_address </td> 
 <td> 一个以太网单播目的地址或者以太网广播地址（0xffffffff）。对于Discovery数据包来说，该域的值是单播或者广播地址，PPPoE Client寻找PPPoE Server的过程使用广播地址，确认PPPoE Server后使用单播地址。对于Session阶段来说，该域必须是Discovery阶段已确定的通信对方的单播地址。 </td> 
 </tr> 
 <tr> 
 <td> Source_address </td> 
 <td> 源设备的以太网MAC地址。 &nbsp; </td> 
 </tr> 
 <tr> 
 <td> Ether_type </td> 
 <td> 16bits，以太网类型。 &nbsp; (a) 0x8863（Discovery阶段或拆链阶段）。 (b) 0x8864（Session阶段）。 </td> 
 </tr> 
 <tr> 
 <td> Ver </td> 
 <td> 4bits，PPPoE版本号，值为0x1。 </td> 
 </tr> 
 <tr> 
 <td> Type </td> 
 <td> 4bits，PPPoE类型，值为0x1。 &nbsp; </td> 
 </tr> 
 <tr> 
 <td> Code </td> 
 <td> 8bits，PPPoE报文类型。 &nbsp; (a) 0x00，表示会话数据。 (b) 0x09，表示PADI报文。 (c) 0x07，表示PADO或PADT报文。 (d) 0x19，表示PADR报文。 (e) 0x65，表示PADS报文。 </td> 
 </tr> 
 <tr> 
 <td> Session_ID </td> 
 <td> 16bits，对于一个给定的PPP会话，该值是一个固定值，并且与以太网Source_address和Destination_address一起实际地定义了一个PPP会话。值0xffff为将来的使用保留，不允许使用。 </td> 
 </tr> 
 <tr> 
 <td> &nbsp;Length </td> 
 <td> 16bits，定义PPPoE的Payload域长度。不包括以太网头部和PPPoE头部的长度。 </td> 
 </tr> 
 <tr> 
 <td> 数据 </td> 
 <td> 有时也称之为净载荷域，在PPPOE的不同阶段该域内的数据内容会有很大的不同。在PPPOE的发现阶段时，该域内会填充一些Tag（标记）；而在PPPOE的会话阶段，该域则携带的是标准的点对点协议包(PPP Packet)。 </td> 
 </tr> 
 </tbody> 
</table>

(3) 在PPPOE 报文数据域中的标记封装格式

![20181202113502159.png][]

从上图中可以看出，标记的封装格式采用的是大家所熟知的TLV 结构，也即是（类型+长度+数据）。

(a) 标记的类型域为2 个字节，下表列出了各种标记类型的含义：

<table> 
 <tbody> 
 <tr> 
 <td> 标记类型 </td> 
 <td> 标记说明 </td> 
 </tr> 
 <tr> 
 <td> 0x0000 </td> 
 <td> 表示PPPOE报文数据域中一串标记的结束，为了保证版本的兼容性而保留，在有些报文中有应用。 </td> 
 </tr> 
 <tr> 
 <td> 0x0101 </td> 
 <td> 服务名，主要用来表明网络侧所能提供给用户的一些服务。 </td> 
 </tr> 
 <tr> 
 <td> 0x0102 </td> 
 <td> 访问集中器名，当用户侧接收到了AC的回应的PADO 报文时，就可获从所携带的标记中获知访问集中器的名子，而且还可以据此来选择相应的访问集中器。 </td> 
 </tr> 
 <tr> 
 <td> 0x0103 </td> 
 <td> 主机唯一标识，类似于PPP数据报文中的标识域，主要是用来匹配发送和接收端的，因为对于广播式的网络中会同时存在很多个PPPOE的数据报文。 </td> 
 </tr> 
 <tr> 
 <td> 0x0104 </td> 
 <td> AC-Cookies ，主要被用来防止恶意性DOS功击。 </td> 
 </tr> 
 <tr> 
 <td> 0x0105 </td> 
 <td> 销售商的标识符。 </td> 
 </tr> 
 <tr> 
 <td> 0x0110 </td> 
 <td> 中继会话ID ，对于PPPOE的数据报文也同样可以像DHCP 报文一样被中断到另外的AC上终结，这个字段则是用来维护另一个连接的。 </td> 
 </tr> 
 <tr> 
 <td> 0x0201 </td> 
 <td> 服务名错误，当请求的服务名不被对端所接受时，会在响应的报文中携带这个标记。 </td> 
 </tr> 
 <tr> 
 <td> 0x0202 </td> 
 <td> 访问集中器名出错。 </td> 
 </tr> 
 <tr> 
 <td> 0x0203 </td> 
 <td> 一般性错误。 </td> 
 </tr> 
 </tbody> 
</table>

(b) 标记的长度域为2 个字节，它用来指明标记数据域的长度。

# 3 接入和总体流程 #

(1) 接入

当用户拨号接入ISP后，就建立了一条从用户PC机到ISP的物理连接。这时，用户PC机向ISP发送一系列LCP分组（封装成多个PPP帧），来建立LCP连接。这些分组及其响应选择了PPP参数以及进行网络层配置，NCP给新接入的用户分配临时IP地址。这样用户PC机就成为因特网上一个有IP地址的主机了。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 2][]

(2) 总体流程

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 3][]

# 3 发现阶段（ PPPoED：PPPoE Discovery ） #

PPPoE的发现阶段一共分为4步，分别 是：PADI(PPPoE Active Discovery Initiation)，PADO(PPPoE Active Discovery Offer)，PADR(PPPoE Active Discovery Request)，PADS(PPPoE Active DiscoverySession- confirmation)。当完成这四步之后，用户主机（PC）和访问集中器（AC）双方就能获知对方唯一的MAC地址和唯一的会话ID。MAC地址和 会话ID共同定义了唯一的PPPoE会话。

PPPoE Discovery的以太网类型域为0x8863。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 4][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 5][]

## 4.1 PADI（ PPPoE Active Discovery Initiation ） ##

主机广播发起分组，分组的目的地址为以太网的广播地址 0xffffffffffff ，CODE（代码）字段值为0x09（ PADI Code）， SESSION-ID（会话ID ）字段值为0x0000。PADI 分组必须至少包含一个服务名称类型的标签（ Service Name Tag ，字段值为0x0101），向接入集中器提出所要求提供的服务。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 6][]

## 4.2 PADO（ PPPoE Active Discovery Offer ） ##

接入集中器收到在服务范围内的PADI 分组，发送PPPoE有效发现提供包分组， 以响应请求。其中CODE字段值为0x07（ PADO Code）， SESSION-ID 字段值仍为0x0000。PADO分组必须包含一个接入集中器名称类型的标签（Access Concentrator Name Tag，字段值为0x0102 ），以及一个或多个服务名称类型标签（ Service Name Tag ，字段值为0x0101），表明可向主机提供的服务种类。PADO和PADI 的 Host-Uniq Tag 值相同。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 7][]

## 4.3 PADR（ PPPoE Active Discovery Request ） ##

主机在可能收到的多个PADO分组中选择一个合适的PADO分组，然后向所选择的接入集中器发送PPPoE有效发现请求分组。其中CODE字段为0x19 （PADR Code）， SESSION\_ID字段值仍为0x0000。PADR分组必须包含一个服务名称类型标签（ Service Name Tag ，字段值为0x0101），确定向接入集线器（或交换机）请求的服务种类。当主机在指定的时间内没有接收到PADO，它应该重新发送它的PADI分组，并且加倍等待时间，这个过程会被重复期望的次数。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 8][]

## 4.4 PADS（ PPPoE Active Discovery Session -confirmation ） ##

接入集中器收到PADR分组后准备开始PPP会话， 它发送一个PPPoE有效发现会话确认PADS分组。其中CODE字段值为0x65（ PADS Code），SESSION-ID 字段值为接入集中器所产生的一个惟一的PPPoE会话标识号码。PADS分组也必须包含一个服务名称类型标签（ Service Name Tag ，字段值为0x0101）以确认向主机提供的服务。当主机收到PADS 分组确认后，双方就进入PPP会话阶段。PADS和PADR的Host-Uniq Tag 值相同。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 9][]

## 4.5 注意 ##

(1) Host-Uniq

在PPPoE发现阶段的四个步骤中，PPPoE头的Payload中始终含有这样一个TLV：

Tag\_Type = 0x0103 (表示为Host-Uniq)

Tag\_Length = 12 （12个字节的长度）

Tag\_Value = 1c:00:00:00:00:00:00:00:38:00:00:00

Host-Uniq为主机唯一标识，类似于PPP数据报文中的标识域，主要是用来匹配发送和接收端的。因为对于 广播式的网络中会同时存在很多个PPPoE的数据报文。

(2) AC-Cookie

PADO和PADR数据包里面都含有 Tag\_Type为AC-Cookie的Tag，20Bytes。Ac-Cookie是为了防止拒绝服务攻击（Denial of Service，简称DOS）。访问集中器（AC）能够根据PADR的源地址来重新产生唯一的Tag\_Value。使用这种方法，AC可以确保PADI的 源地址是可达的，并对该地址的并行会话数进行限制。

# 5 会话阶段（ PPPoES：PPPoE Session） #

PPP会话的建立，需要两端的设备都发送LCP数据包来配置和测试数据通信链路。用户主机与接入集中器根据在发现阶段所协商的PPP 会话连接参数进行PPP 会话。一旦PPPoE会话开始， PPP数据就可以以任何其他的PPP封装形式发送。所有的以太网帧都是单播的。PPPoE会话的SESSION-ID一定不能改变，并且必须是发现阶段分配的值。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 10][]

## 5.1 LCP协商阶段（ LCP： Link Control Protocol ） ##

LCP的Request 主机和AC 都要给对方发送， LCP协商阶段完成最大传输单元（ MTU），是否进行认证和采用何种认证方式（ Authentication Type ）的协商。

(1) LCP协议数据报文分类

<table> 
 <tbody> 
 <tr> 
 <td> 报文类型 </td> 
 <td> 说明 </td> 
 </tr> 
 <tr> 
 <td> 链路配置报文 </td> 
 <td> 用来建立和配置一条链路，主要包括Configure-Request 、Configure-Ack 、Configure-Nak 和Configure-Reject 报文。 </td> 
 </tr> 
 <tr> 
 <td> 链路维护报文 </td> 
 <td> 用来管理和调试链路， 主要包括Code-Reject、Protocol-Reject 、Echo-Request、Echo-Reply 和Discard-Request 报文。 </td> 
 </tr> 
 <tr> 
 <td> 链路终止报文 </td> 
 <td> 用来终止一条链路，主要包括Terminate-Request 和Terminate-Reply 报文。 </td> 
 </tr> 
 </tbody> 
</table>

(2) LCP协商过程

LCP 协商的过程如下：协商双方互相发送一个LCP Config-Request 报文，确认收到的Config-Request 报文中的协商选项，根据这些选项的支持与接受情况，做出适当的回应。若两端都回应了Config-ACK，则标志LCP链路建立成功，否则会继续发送Request 报文，直到对端回应了ACK报文为止。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 11][]

说明：

<table> 
 <tbody> 
 <tr> 
 <td> 字段 </td> 
 <td> 说明 </td> 
 </tr> 
 <tr> 
 <td> Config-ACK </td> 
 <td> 若完全支持对端的LCP选项， 则回应Config-ACK报文， 报文中必须完全携 带对端Request 报文中的选项。 </td> 
 </tr> 
 <tr> 
 <td> Config-NAK </td> 
 <td> 若支持对端的协商选项，但不认可该项协商的内容，则回应Config-NAK报文，在Config-NAK 的选项中填上自己期望的内容，如:对端MRU 值为1500，而自己期望MRU 值为1492，则在Config-NAK 报文中埴上自己的期望值1492。 </td> 
 </tr> 
 <tr> 
 <td> Config-Reject </td> 
 <td> 若不能支持对端的协商选项，则回应Config-Reject 报文，报文中带上不能支持的选项，如Windows 拨号器会协商CBCP（被叫回呼） ，而ME60 不支持CBCP功能，则回将此选项拒绝掉。 </td> 
 </tr> 
 </tbody> 
</table>

### 5.1.1 协商实例 ###

若不能支持对端的协商选项，则回应Config-Reject 报文，报文中带上不能支持的选项，如Windows 拨号器会协商CBCP（被叫回呼） ，而ME60 不支持CBCP功能，则回将此选项拒绝掉。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 12][]

(1) 客户端配置协商

(a) win7客户端发送 Configure-Request

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 13][]

(b) ubuntu服务端不支持CBCP功能，则回将此选项拒绝掉。回应Configure-Reject

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 14][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 15][]

(d) ubuntu 服务端发送 Configure-Ack

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 16][]

(2) 服务端配置协商

(a) ubuntu 服务端发送 Configure-Request

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 17][]

(b) win7 客户端发送 Configure-Ack

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 18][]

## 5.2 认证阶段（ PPP Authentication：PAP/CHAP） ##

会话双方通过LCP协商好的认证方法进行认证， 如果认证通过了， 才可以进行下面的网络层

的协商。认证过程在链路协商结束后就进行。

(1) PAP（Password Authentication Protocol，口令认证协议）认证

PAP为两次握手协议，它通过用户名及口令来对用户进行验证。PAP验证过程如下：

当两端链路可相互传输数据时， 被验证方发送本端的用户名及口令到验证方， 验证方根据本端的用户表（或Radius 服务器）查看是否有此用户，口令是否正确。如正确则会给对端发送Authenticate-ACK 报文， 通告对端已被允许进入下一阶段协商； 否则发送NAK报文， 通告对端验证失败。此时，并不会直接将链路关闭。只有当验证不过次数达到一定值（缺省为10）时，才会关闭链路。

PAP的特点是在网络上以明文的方式传递用户名及口令，如在传输过程中被截获，便有

可能对网络安全造成极大的威胁。因此，它适用于对网络安全要求相对较低的环境。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 19][]

(2) CHAP（Challenge Handshake Authentication Protoco，l 质询握手认证协议）认证

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 20][]

CHAP为三次握手协议。只在网络上传输用户名，并不传输用户口令，因此它的安全性要比PAP高。CHAP的验证过程为：

首先由验证方（ Server）向被验证方（ Client）发送一些随机产生的报文，并同时将本端的主机名附带上一起发送给被验证方。被验证方接到对端对本端的验证请求（ Challenge）时，便根据此报文中验证方的主机名和本端的用户表查找用户口令字， 如找到用户表中与验证方主机名相同的用户，便利用报文ID、此用户的密钥用Md5 算法生成应答（ Response），随后将应答和自己的主机名送回。验证方接到此应答后，用报文ID、本方保留的口令字（密钥）和随机报文用Md5 算法得出结果， 与被验证方应答比较， 根据比较结果返回相应的结果（ACK or NAK）

(a) 接受认证端发送Challenge。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 21][]

(b) 申请认证端发验证请求报文。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 22][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 23][]

经过以上三次报文交互后， CHAP认证完成。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 24][]

## 5.3 NCP协商阶段（ NCP： Network Control Protocol） ##

NCP有很多种，如IPCP、BCP、IPv6CP，最为常用的是IPCP（ Internet Protocol Control Protocol ）协议。NCP的主要功能是协商PPP报文的网络层参数， 如IP 地址， DNS Server IP地址，WINS Server IP 地址等。PPPoE用户主要通过IPCP来获取访问网络的IP 地址或IP 地址段。NCP流程与LCP流程类似，用户与ME 设备之间互相发送NCP Config-Request 报文并且互相回应NCP Config-Ack报文后，标志NCP己协商完，用户上线成功， 可以正常访问网络了。IPCP的协商过程是基于PPP 状态机进行协商的。经过双方协商，通过配置请求、配置确认、配置否认等包文交换配置信息，最终由initial ( 或closed)状态变为Opened 状态。IPCP状态变为Opened 的条件必须是发送方和接收方都发送和接收过确认包文。IPCP 协商过程中，协商包文可包含多个选项，即参数。各个选项的拒绝或否认都不能影响IPCP的UP，IPCP可以无选项协商，无选项协商也同样能够UP。选项有IP Address、网

关、掩码等，其中IP Address 是最重要的一个选项， 有些厂家的实现必须这个选项得到确认，大多数厂家的实现允许这个选项为空。

NCP的基本协商流程见下图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 25][]

用户和接入设备对IP 服务阶段的一些要求进行多次协商，以决定双方都能够接收的约定。

如： IP 业务阶段使用的IP 压缩协议等。双方的协议是通过报文中包含的Option 项进行协商的，每一个Option 都是一个需要协商的问题。最后双方都需要对方答复Configure\_Ack 的同意报文。

(1) Configuration Request

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 26][]

(2) Configuration Ack

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 27][]

## 5.4 会话维持（ Session Keep-alive） ##

设备主动发送Echo Request 进行PPPoE心跳保活， 若3 次未得到服务器的响应， 则设备主动释放地址。发LCP Echo Request 的时候，魔术字字段要和之前通信的Configure\_Request 使用的魔术字字段保持一致。

有些设备或终端不支持主动发送Echo-Request 报文, 只能支持回应Echo-Reply 报文。

## 5.5 会话结束（ Session Termination） ##

PPPoE 还有一个PADT（ PPPOE Active Discovery Terminate）分组，它可以在会话建立后的任何时候发送， 来终止PPPoE会话，也就是会话释放。它可以由主机或者接入集中器发送，目的地址填充为对端的以太网的MAC 地址。当对方接收到一个PADT（ PPPOE Active Discovery Terminate）分组，就不再允许使用这个会话来发送PPP 业务。PADT 分组不需要任何标签，其CODE字段值为0xa7（ PADT Code），SESSION-ID字段值为需要终止的PPP会话的会话标识号码。在发送或接收PADT后，即使正常的PPP终止分组也不必发送。PPP对端应该使用PPP协议自身来终止PPPoE会话， 但是当PPP不能使用时，可以使用PADT。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 28][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70]: /images/20220412/b41d9316148e4d018407e91ccd95bef0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 1]: /images/20220412/f564fc4426144b9e8d2c9e0e26355dd8.png
[20181202113502159.png]: /images/20220412/f6bd4e4ccefa45ce913f38ee8b69e105.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 2]: /images/20220412/cc72872988a2460f8aa4b4f07c9e8be5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 3]: /images/20220412/72f2f1da67bf421da1640e538a8a17d9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 4]: /images/20220412/43699f79441a49ec8d3ca30ff5a89ca5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 5]: /images/20220412/8ca9691d9edb45639597e5700c3e3746.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 6]: /images/20220412/ea808d18207649719e365d2f406849bc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 7]: /images/20220412/66ea6629a019488da01b0b1cfc996269.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 8]: /images/20220412/b44f728019914182baaf471f8623a7f6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 9]: /images/20220412/741e1cd26dec4c88bf4987141f1456f1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 10]: /images/20220412/8cb253464f9540a3ab284b6bc76353b0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 11]: /images/20220412/3f4276496cd14c369735c610fb2693cd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 12]: /images/20220412/d4a843bfaf1a4ef9aa193ab8eb0858cd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 13]: /images/20220412/272671fe26454074b3f90cc065407fe0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 14]: /images/20220412/e610ff18dd694fbabffbe35ccab97431.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 15]: /images/20220412/a9aa5e5104d1413ab0f35d3a51d6f88a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 16]: /images/20220412/95e6a5539a274369be150234be25bf50.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 17]: /images/20220412/82c1787def6c44648ed756a3153b2b6a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 18]: /images/20220412/9e70dba4d0214888881b48c4b87ccf29.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 19]: /images/20220412/e05f603c01b4489497ea10644abc3abb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 20]: /images/20220412/eac7fb005201484490fd999cddd73b67.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 21]: /images/20220412/582004df7e1d47c3b1abb4ec3f706de8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 22]: /images/20220412/0b95deae8ecd4e76a4f92ac697f13ace.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 23]: /images/20220412/096156fab4234639890b642cc4481966.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 24]: /images/20220412/1bc59043f34e4d0ba2580737b1039ee0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 25]: /images/20220412/49b93440626848ec8377fda9b594c4e5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 26]: /images/20220412/801bade0c5c445a4b4e6888a904c92de.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 27]: /images/20220412/38f9a74d36cc4d69b95be0fd5473163c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE4NTc2ODM_size_16_color_FFFFFF_t_70 28]: /images/20220412/1b531013481a479f871e6d4e264bfed7.png