PPPOE 详解

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帧格式如下

 

PPPOE 详解_第1张图片

 

 

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

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

 

数值

说明

0x0021

信息字段是IP数据报。

0xC021

信息字段是链路控制数据LCP。

0x8021

信息字段是网络控制数据NCP。

0xC023

信息字段是安全性认证PAP。

0xC025

信息字段是LQR。

0xC223

信息字段是安全性认证CHAP。

 

 

 

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

 

PPPOE字段如下:

 

 

PPPOE 详解_第2张图片

 

各个字段解释如下: 

 

字段

说明

Destination_address

一个以太网单播目的地址或者以太网广播地址(0xffffffff)。对于Discovery数据包来说,该域的值是单播或者广播地址,PPPoE Client寻找PPPoE Server的过程使用广播地址,确认PPPoE Server后使用单播地址。对于Session阶段来说,该域必须是Discovery阶段已确定的通信对方的单播地址。

Source_address

源设备的以太网MAC地址。  

Ether_type

16bits,以太网类型。

 

(a) 0x8863(Discovery阶段或拆链阶段)。

(b) 0x8864(Session阶段)。

Ver

4bits,PPPoE版本号,值为0x1。

Type

4bits,PPPoE类型,值为0x1。  

Code

8bits,PPPoE报文类型。

 

(a) 0x00,表示会话数据。

(b) 0x09,表示PADI报文。

(c) 0x07,表示PADO或PADT报文。

(d) 0x19,表示PADR报文。

(e) 0x65,表示PADS报文。

Session_ID

16bits,对于一个给定的PPP会话,该值是一个固定值,并且与以太网Source_address和Destination_address一起实际地定义了一个PPP会话。值0xffff为将来的使用保留,不允许使用。

 Length

16bits,定义PPPoE的Payload域长度。不包括以太网头部和PPPoE头部的长度。

数据

有时也称之为净载荷域,在PPPOE的不同阶段该域内的数据内容会有很大的不同。在PPPOE的发现阶段时,该域内会填充一些Tag(标记);而在PPPOE的会话阶段,该域则携带的是标准的点对点协议包(PPP Packet)。

 

 

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

 

PPPOE 详解_第3张图片

 

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

 

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

 

标记类型

标记说明

0x0000

表示PPPOE报文数据域中一串标记的结束,为了保证版本的兼容性而保留,在有些报文中有应用。

0x0101

服务名,主要用来表明网络侧所能提供给用户的一些服务。

0x0102

访问集中器名,当用户侧接收到了AC的回应的PADO 报文时,就可获从所携带的标记中获知访问集中器的名子,而且还可以据此来选择相应的访问集中器。

0x0103

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

0x0104

AC-Cookies ,主要被用来防止恶意性DOS功击。

0x0105

销售商的标识符。

0x0110

中继会话ID ,对于PPPOE的数据报文也同样可以像DHCP 报文一样被中断到另外的AC上终结,这个字段则是用来维护另一个连接的。

0x0201

服务名错误,当请求的服务名不被对端所接受时,会在响应的报文中携带这个标记。

0x0202

访问集中器名出错。

0x0203

一般性错误。

 

 

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

(c) 标记的数据域中用来放置不同类型标记所对应的相关数据。

 

 

 

 

3 接入和总体流程

 

(1) 接入

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

PPPOE 详解_第4张图片

 

 

(2) 总体流程

PPPOE 详解_第5张图片

 

 

 

 

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。

 

 

PPPOE 详解_第6张图片

 

PPPOE 详解_第7张图片

 

 

 

4.1 PADI( PPPoE Active Discovery Initiation )

 

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

 

PPPOE 详解_第8张图片

 

 

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 值相同。

 

PPPOE 详解_第9张图片

 

 

4.3 PADR( PPPoE Active Discovery Request )

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

 

PPPOE 详解_第10张图片

 

 

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 值相同。

 

PPPOE 详解_第11张图片

 

 

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一定不能改变,并且必须是发现阶段分配的值。

PPPOE 详解_第12张图片

 

 

 

5.1 LCP协商阶段( LCP: Link Control Protocol )

 

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

 

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

报文类型

说明

链路配置报文

用来建立和配置一条链路,主要包括Configure-Request 、Configure-Ack 、Configure-Nak 和Configure-Reject 报文。

链路维护报文

用来管理和调试链路, 主要包括Code-Reject、Protocol-Reject 、Echo-Request、Echo-Reply 和Discard-Request 报文。

链路终止报文

用来终止一条链路,主要包括Terminate-Request 和Terminate-Reply 报文。

 

 

(2) LCP协商过程

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

 

PPPOE 详解_第13张图片

 

 

说明:

字段

说明

Config-ACK

若完全支持对端的LCP选项, 则回应Config-ACK报文, 报文中必须完全携

带对端Request 报文中的选项。

Config-NAK

若支持对端的协商选项,但不认可该项协商的内容,则回应Config-NAK报文,在Config-NAK 的选项中填上自己期望的内容,如:对端MRU 值为1500,而自己期望MRU 值为1492,则在Config-NAK 报文中埴上自己的期望值1492。

Config-Reject

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

 

 

 

 

5.1.1 协商实例

 

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

 

PPPOE 详解_第14张图片

 

 

(1) 客户端配置协商

 

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

 

PPPOE 详解_第15张图片

 

 

 

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

PPPOE 详解_第16张图片

 

(c) win7客户端重新发送 Configure-Request

PPPOE 详解_第17张图片

 

 

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

PPPOE 详解_第18张图片

 

 

(2) 服务端配置协商

 

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

PPPOE 详解_第19张图片

 

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

PPPOE 详解_第20张图片

 

 

 

 

5.2 认证阶段( PPP Authentication:PAP/CHAP)

 

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

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

 

 

(1) PAP(Password Authentication Protocol,口令认证协议)认证

 

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

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

 

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

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

 

 

PPPOE 详解_第21张图片

 

 

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

 

PPPOE 详解_第22张图片

 

 

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

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

 

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

PPPOE 详解_第23张图片

 

 

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

PPPOE 详解_第24张图片

 

(c) 接受认证端回应认证接受报文。

PPPOE 详解_第25张图片

 

 

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

PPPOE 详解_第26张图片

 

 

 

 

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的基本协商流程见下图:

 

PPPOE 详解_第27张图片

 

 

 

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

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

 

(1) Configuration Request

 

PPPOE 详解_第28张图片

 

 

(2) Configuration Ack

PPPOE 详解_第29张图片

 

 

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。

 

 

PPPOE 详解_第30张图片

 

 

 

 

 

 

 

 

 

你可能感兴趣的:(网络基础原理)