PPPOE

简介

全称：Point-to-Point Protocol Over Ethernet

中文：以太网点对点协议

RFC：2516

数据链路层

将点对点协议（PPP）封装在以太网框架中的一种网络隧道协议。由于协议中集成PPP协议，所以实现出传统以太网不能提供的身份验证、加密以及压缩等功能，也可用于缆线调制解调器（cable modem）和数字用户线路（DSL）等以以太网协议向用户提供接入服务的协议体系。本质上，它是一个允许在以太网广播域中的两个以太网接口间创建点对点隧道的协议。它使用传统的基于PPP的软件来管理一个不是使用串行线路而是使用类似于以太网的有向分组网络的连接。这种有登陆和口令的标准连接，方便了接入供应商的记费。并且，连接的另一端仅当PPPoE连接接通时才分配IP地址，所以允许IP地址的动态复用。

报文格式

格式简介

VER：有4bits，必须设置为0x01(此版本协议规范规定) TYPE：有4bits，必须设置为0x01(此版本协议规范规定) CODE：有8bits，用于标识报文类型，其中0x00表示会话数据，0x09表示PADI，0x07表示PADO或PADT，0x19表示PADR，0x65表示PADS SESSION_ID：有16bits，在一个给定ppp会话中值是固定值，与以太头中原地址与目的地址标识一个ppp会话。其中0xffff是保留字段，不能被使用 LENGTH：有16bits，定义pppoe的payload长度，不包含以太或pppoe的头部长度

建立

组网环境： 通常的pppoe组网是CE(用户设备以下统称ce)->网络->pppoe服务器->RADIUS进行认证通讯

实现过程

图解流程顺序

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
Participant client as ce
Participant pppoe_server as se
Participant RADIUS as ra

activate ce
ce -->o net: 用户pppoe认证
activate se
ce -> se: 1. PADI
se -> ce: 2. PADO
ce -> se: 3. PADR
se -> ce: 4. PADS
ce -> se: 5. 会话开始
ce -> se: 6. lcp req
se -> ce: 7. lcp ack
ce -> se: 8. lcp req
se -> ce: 9. lcp ack
se -> ce: 10. challenge
ce -> se: 11. 验证请求Response
se -> ra: 12. 认证请求
activate ra
ra -> se: 13. 接受认证
se -> ce: 14. 认证成功
ce -> se: 15. Configure-request
se -> ce: 16. Configure-ack
ce -> se: 17. Configure-request
se -> ce: 18. Configure-ack
se -> ra: 19. 通知用户上线
ra -> se: 20. 用户上线确认
se -> ce: 21. 用户上线应答
se -> ra: 22. 计费请求开始
ra -> se: 23. 计费请求应答

deactivate ra
deactivate se
deactivate ce

阶段详解

发现阶段

其中padi,pado,pads,padr为discover阶段

  • padi - PPPOE Active DiscoveryInitiation PADI是由CE发出的广播报文，报文中的CODE值必须设置为0x09且SESSION_ID必须为0x0000，PADI报文中必须至少包含一个服务名称类型的标签(tag值为0x0101)，整个 PADI 数据包（包括 PPPoE标头）不得超过 1484 个八位字节，以留出足够的空间用于中继代理添加 Relay-Session-Id TAG。
  • pado - PPPOE Active Discovery Offer pppoe服务器收到在服务范围内的PADI分组，发送PPPoE有效发现提供包PADO，以响应请求。其中CODE字段值为0x07，SESSION-ID字段值仍为0x0000。PADO分组必须包含一个AC-Name的标签（标签类型字段值为0x0102），以及一个或多个服务名称类型标签，表明可向主机提供的服务种类。当服务器不能不能处理PADI服务时，不得相应PADO。
  • padr - PPPOE Active Discovery Request CE在可能收到的多个PADO分组中选择一个合适的PADO分组，然后向所选择的pppoe服务器发送PPPoE有效发现请求分组PADR。其中CODE字段为0x19，SESSION_ID字段值仍为0x0000。PADR分组必须包含一个服务名称类型标签，确定向接入集线器（或交换机）请求的服务种类。当主机在指定的时间内没有接收到PADO，它应该重新发送它的PADI分组，并且加倍等待时间，这个过程会被重复期望的次数。
  • pads - PPPOE Active DiscoverySession-confirmation pppoe服务器收到PADR分组后准备开始PPP会话，它发送一个PPPoE有效发现会话确认PADS分组。其中CODE字段值为0x65，SESSION-ID字段值为接入集中器所产生的一个惟一的PPPoE会话标识号码。PADS分组也必须包含一个AC-Name的标签以确认向主机提供的服务。当主机收到PADS分组确认后，双方就进入PPP会话阶段。
  • padt - PPPoE Active Discovery Terminate padt是用于CE与pppoe服务器之间结束通讯的报文，该数据包可在会话建立后随时发送，以便表示 PPPoE 会话已终止。 目的地地址字段是单播以太网地址，CODE 字段设置为 0xa7 必须设置 SESSION_ID，以指示哪个会话将终止， 无需 TAG。 收到 PADT 时，不允许再发送 PPP 流量使用该会话。 即使是正常的 PPP 终止数据包也不得在发送或接收 PADT 之后发送。 PPP 对等体应使用PPP 协议本身会导致 PPPoE 会话中断，但 PADT 可以在 PPP 无法使用时中断会话。

PPP会话阶段

一旦PPPoE会话开始，PPP数据就可以以任何其他的PPP封装形式发送。所有的以太网帧都是单播的。ETHER_TYPE字段设置为 0x8864，PPPoE CODE 必须设置为 0x00，该 PPPoE 会话的 SESSION_ID 不得更改，并且必须是在 "发现 "阶段分配的值。 PPPoE 有效载荷包含一个PPP 帧。 帧以 PPP 协议 ID 开始。

LCP协商

全称：Link Control Protocol 中文：链路控制协议

此阶段主要是协商链路的一些参数，如最大接收单元MRU、Magic Number，以及后续认证时使用的协议等。LCP协商分为 ConfigureRequest：用于发起协商 ConfigureAck：如果支持对端发送的协商协议，也完全认可协商的内容，发送ACK表示确认，且报文中必须含有对端携带的全部选项 ConfigureNak：如果支持对端发送的协商协议，但是不同意对端协商的内容，可以发送Nak，并填写本端期望的值 ConfigureReject：如果不支持对端发送的协商协议，则填写不支持的协议选项并发送 Echo Request：LCP协商成功后用于保活

SessionID就是PADS获得的SessionID，主要协商了MRU（Maximun Receive Ubit），并且提出认证使用的Magic Number。一般而言，MRU和MTU取值相同，PPPOE的最大MTU不能超过1492。计算方法如下: 首先，以太网帧大小限制： Ethernet MinSize = 64 Byte Ethernet MaxSize = 1518 Byte 去掉以太网帧头(6字节SRCMAC+6字节DSTMAC+2字节TYPE+4字节CRC)后的净荷为：EthernetIP MTU =1518–18= 1500 B 所以，再去掉(6字节PPPoE_SESSION+2字节PPP_HEADER)的开销，所以PPPOE的MRU最大值为：PPPoEMTU/MRU=1500–8=1492B。

Magic-number选项用来协商双方的魔术字，两端魔术字不能重复，魔术字可用来检测链路的环回情况,该选项提供了一种探测短路连接和其它数据链路层异常的方法当一方接收到带有魔数选项的配置请求数据帧后，将接收到的魔数与上次发送的魔数进行比较，如果不相同就认为没有发生短路。如果两个魔数相同，则需要发送一个携带不同魔数的配置否认帧，然后将接收到的魔数与发送的魔数进行比较。

在广域链路上，最常用的一种检测链路的方法就是在远端将发送和接受短接成环路，在本端发送的信号如果能被自己成功的接受到，那么线路就有可能是Ok的，这就是LoopBack测试。如果环路在测试之后并未撤掉，PPP又没有引如Magic-Number的话，就可能自己和自己建立PPP关系。

流程上服务器与CE互发Request进行协商，如果两段都回复的ACK则表示协商成功，则进入下一阶段

PAP/CHAP阶段

PAP（Password Authentication Protocol）验证为两次握手验证，密码为明文。 PAP验证的过程如下：

  1. 被验证方发送用户名和密码到验证方；
  2. 验证方根据本端用户表查看是否有此用户以及密码是否正确，然后返回不同的响应。

注意：PAP不是一种安全的验证协议。当验证时，口令以明文方式在链路上发送，并且由于完成PPP链路建立后，被验证方会不停地在链路上反复发送用户名和口令，直到身份验证过程结束，所以不能防止攻击。

CHAP（Challenge-Handshake Authentication Protocol）验证为三次握手验证，密码为密文（密钥）。CHAP验证过程如下：

  1. Challenge：验证方主动发起验证请求，验证方向被验证方发送一些随机产生的报文，并同时将本端的用户名附带上一起发送给被验证方；
  2. Response：若被验证方接到验证方的验证请求后，检查本端接口上是否配置了缺省的CHAP密码，如果配置了则被验证方利用报文ID、该缺省密码和MD5算法对该随机报文进行加密，将生成的密文和自己的用户名发回验证方；若被验证方检查发现本端接口上没有配置缺省的CHAP密码，则被验证方根据此报文中验证方的用户名在本端的用户表查找该用户对应的密码，如果在用户表找到了与验证方用户名相同的用户，便利用报文ID、此用户的密钥（密码）和MD5算法对该随机报文进行加密，将生成的密文和被验证方自己的用户名发回验证方；
  3. result:验证方用自己保存的被验证方密码和MD5算法对原随机报文加密，比较二者的密文，根据比较结果返回不同的响应。
NCP阶段

此阶段主要用于协商报文中的网络层参数，如IPCP，IPV6CP等 NCP的流程与LCP类似 NCP协商成功后表示CE正式上线，之后会与RADIUS进行计费请求并计费