初识PPPoE协议

网络 网络管理
PPPoE协议是我们这次将要重点讲解的协议,在文章中,我们分析了它的工作原理,数据报文格式,数据报文中Tag(标记)的格式等内容。

大家因该都知道PPPoE协议是以太网中点对点传输协议。那么对于这个协议的一些工作原理,特点分析,以及应用内容,我们在本文中将要为大家仔细汇总一下,希望对大家的学习能够有所帮助。

一、 PPPOE协议介绍

PPPOE,全称Point-to-Point Protocol Over Ethernet,它工作在OSI的数据链路层,PPPOE协议提供了在广播式的网络(如以太网)中多台主机连接到远端的访问集中器(我们对目前能完成上述功能的设备为宽带接入服务器)上的一种标准。

1. PPPOE的工作原理

PPPOE协议共包括两个阶段,即PPPOE的发现阶段(PPPOE Discovery Stage)和PPPOE的会话阶段(PPPOE Session Stage)。而两者的主要区别在于只是在PPP的数据报文前封装了PPPOE的报文头。

当一个主机希望能够开始一个PPPOE会话时,它首先会在广播式的网络上寻找一个访问集中器,当然可能网络上会存在多个访问集中器时,对于主机而言则会根据各访问集中器(AC,Access Concentration)所能提供的服务或用户的预先的一些配置来进行相应的选择。当主机选择完了所需要的访问集中器后,就开始和访问集中器建立一个PPPOE会话进程。在这个过程中访问集中器会为每一个PPPOE会话分配一个唯一的进程ID,会话建立起来后就开始了PPPOE的会话阶段,在这个阶段中已建立好点对点连接的双方(这种点对点的结构与PPP不一样,它是一种逻辑上的点对点关系)就采用PPP协议来交换数据报文,从而完成一系列PPP的过程,最终将在这点对点的逻辑通道上进行网络层数据报的传送。

2. PPPOE的数据报文格式

我们简要介绍一下PPPOE的数据报文格式。PPPOE的数据报文是被封装在以太网帧的数据域内的。简单来说我们可能把PPPOE报文分成两大块,,一大块是PPPOE的数据报头,另一块则是PPPOE的净载荷(数据域),对于PPPOE报文数据域中的内容会随着会话过程的进行而不断改变。

◆PPPOE数据报文最开始的4位为版本域,协议中给出了明确的规定,这个域的内容填充0x1。

◆紧接在版本域后的4位是类型域,协议中同样规定,这个域的内容填充为0x1。

◆代码域占用1个字节,对于PPPOE 的不同阶段这个域内的内容也是不一样的。

◆会话ID点用2个字节,当访问集中器还未分配唯一的会话ID给用户主机的话,则该域内的内容必须填充为0x0000,一旦主机获取了会话ID后,那么在后续的所有报文中该域必须填充那个唯一的会话ID值。

◆长度域为2个字节,用来指示PPPOE数据报文中净载荷的长度。

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

这里我们主要来介绍一下PPPOE发现阶段的报文格式以及它的报文:

1) PPPOE数据报文中Tag(标记)的格式

对于发现阶段的PPPOE数据报文而言,它的净载荷可能包含零个或多个Tag(标记),实际上这些标记的意义非常类似于PPP配置参数选项,它同样也是要经过协商的。对于PPPOE协议而言,没有像PPP的配置参数选项那样定义了很多细节,而只是一个初略的定义,因此在实际当中实现这个过程会依据不同厂商的设备有不同。标记的类型域为2个字节,下表列出了各种标记类型的含义:

标记类型 标记说明

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

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

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

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

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

0x0105 销售商的标识符。

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

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

0x0202 访问集中器名出错。

0x0203 一般性错误。

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

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

2) PPPOE发现阶段的数据报文

PPPOE的发现阶段可分为四步,其实这个过程也是PPPOE四种数据报文的交换的一个过程。当完成这四步后,用户主机与访问集中器双方就能获知对方的MAC地址和唯一的会话ID号,从而进入到下一个阶段(PPPOE的会话阶段)。实际上双方在互相知道了对方的MAC地址后,就已经在广播式的网络上确定了一一的对应关系,为了保证这个连接的有效性,同时使PPPOE协议能更加灵活的运用,因此还加入了会话ID字段,通过这两个条件就可完成确定双方点对点的关系。

在这个阶段一开始,由于接入用户并不知道访问集中器的MAC地址,则使用类似于ARP解析的过程的机制来获取访问集中器的MAC地址。首先由接入用户侧发起一个初始化的广播报文,对于访问集中器如果配置了PPPOE的业务时,它会时实检测网络上的数据包,当发现以太网数据帧中所承载的是PPPOE报文时(通过协议域的内容来区分),就会将其交给相应的模块去处理。当收到初始化报文后,访问集中器会向该用户回应一个报文。如果网络上存在很多这样的访问集中器且都收到了用户侧发送的初始化报文时,它们也都会向用户侧会送一个确认报文,如果该用户收到这个报文后,则会依据报文中所携带的内容或本端的一些配置来选择一个唯一的访问集中器进行会话。到此时已完成了前两步了,那么剩下的两步则是协商一些所提供的服务选项和获取PPPOE会话阶段所必须的会话ID值。

说明:在这个阶段,所有数据报文是被承载在以太网的数据域中的,而且以太网数据帧的协议域始终为0x8863。

在PPPOE发现阶段的四步的过程中,PPPOE会遇到PADI、PADO、PADR和PADS这四种报文。PPPOE中的PADT报文是用来终止一条会话的。

◆PADI(PPPOE Active Discovery Initiation)报文

PPPOE发现阶段的***步,也即是由用户侧首先发送这样一个报文。用户主机是以广播的方式发送这个报文,所以该报文所对应的以太网帧的目的地址域应填充为全1,而源地址域填充用户主机的MAC地址。广播包可能会被多个访问集中器接收到。

◆PADO(PPPOE Active Discovery Offer)报文

PPPOE发现阶段的第二步,也即是由访问集中器回应各用户主机发送的PADI报文,此时该报文所对应的以太网帧的源地址填充访问集中器的MAC地址,而目的地址则填充从PADI中所获取的用户主机的MAC地址。

◆PADR(PPPOE Active Discovery Request)报文

PPPOE发现阶段的第三步,也即是由用户主机向访问服务器发送单播的请求报文。当用户主机收到PADO报文后,会从这些报文中挑选一个访问集中器作为后续会话的对象。由于用户主机在收到PADO报文后,就获知了访问集中器的MAC地址,因此PADR报文所以应的以太网帧的源地址填充用户主机的MAC地址,而以太网的目的地址填充为访问集中器的MAC地址。

◆PADS(PPPOE Active Discovery Session-confirmation)报文

PPPOE发现阶段的第四步,也即是***一步,此时访问集中器当收到PADR报文时,就准备进入开始一个PPP的会话了,而此时访问集中器会为在这个会话分配一个唯一的会话进程ID,并在发送给主机的PADS报文中携带上这个会话ID。当然如果访问集中器不满足用户所申请的服务的话,则会向用户发送一个PADS报文,而其中携带一个服务名错误的标记,而且此时该PADS报文中的会话ID填充0x0000。

◆PADT(PPPOE Active Discovery Terminate)报文

PADT报文可能在会话进行开始之后的任意时间内被发送,主要是用来终止一个PPPOE会话的止。它可以由主机或访问集中器发送,目的地址填充为对端的以太网的MAC地址

二、 PPPOE Discovery详细解码

捕获PPPOE数据包,可以看出这是PPPOE发现阶段的***步的PADI报文,我们来详细说明:

◆版本:1,协议中给出了明确的规定,这个域的内容填充0x1。

◆类型:1协议中也给了明确的规定,这里也职能填充0x1

◆代码:0x09,表示该报文是发现阶段的 PADI报文

◆会话ID:0,表示还没有会话ID

◆长度:16,表示PPPOE数据报文中净载荷的长度

◆PPP发现标记:在面我们列出的标记类型表可以看出

责任编辑:佟健 来源: 百度空间
相关推荐

2010-09-02 15:50:01

PPPoE协议

2010-09-06 13:53:21

PPPoE协议

2010-07-01 16:41:33

PPPOE协议

2010-09-07 12:06:46

PPPoE协议

2012-03-05 13:41:58

OpenFlow

2010-09-10 14:25:00

Daytime协议

2010-07-08 12:34:46

HART协议

2010-09-16 13:03:02

PPPoE协议配置

2010-07-06 17:47:44

PPPoE协议

2010-09-07 12:02:50

PPPoE协议

2010-09-07 14:21:22

PPPoE协议

2010-09-07 14:47:42

2010-07-06 17:05:22

PPPOE协议

2010-06-12 17:12:21

PPPOE协议

2010-09-06 16:35:18

PPPoE协议

2010-09-06 16:48:23

PPPoE协议BAS

2010-09-17 15:28:45

Internet网络协

2010-09-27 14:31:35

PPPoE协议配置

2010-09-06 14:55:30

2010-06-17 14:57:44

RS-232协议
点赞
收藏

51CTO技术栈公众号