PPPoE拨号过程

PPPoE(PPP over Ethernet)是在以太网上建立PPP连接，由于以太网技术使用广泛，而PPP协议在传统的拨号上网应用中显示出良好的可扩展性和优质的管理控制机制，二者结合而成的PPPoE协议得到了宽带接入运营商的认可并广为采用。 PPPoE不仅有以太网的快速简便的特点，同时还有PPP的强大功能，任何能被PPP封装的协议都可以通过PPPoE传输。

PPPoE的数据报文是被封装在以太网帧的数据域内的。

*以太网帧头包括：

1. 目的MAC地址(该阶段为ffffffffffff的广播地址)

2. 源MAC地址（客户端MAC地址）

3. 以太网协议类型(该阶段为0x8863,表示为发现阶段)。

*PPPoE数据报文的格式：

1. PPPoE数据报文最开始的4位为版本域（Version），协议中给出了明确的规定，这个域填充的内容为0x01.

2. 版本域后是4位的类型域（Type），根据协议规定，这个域填充的内容也是0x01.

3. 代码域（Code）占用一个字节，对于PPPoE的不同阶段这个域内容也不一样。

4. 会话ID（Session ID）占用两个字节，当访问集中器（Access Concentrator）还没有分配唯一的会话ID给用户主机的话，改域的内容必须填充为0x0000；一旦主机获取了会话ID后，那么在后续的所有报文里面必须填充那个唯一的会话ID。

5. PPPoE的Payload长度（Length）占两个字节。PPPoE的Payload可以由多个TLV组成，每个包括Tag_Type，Tag_Length，Tag_Vlaue。

PPPoE建立过程可以分为Discovery阶段和PPP会话阶段。Discovery阶段是一个无状态的阶段，该阶段主要是选择接入服务器，确定所要建立的PPP会话标识符Session ID，同时获得对方点到点的连接信息；PPP会话阶段执行标准的PPP过程

一、发现阶段（Discovery）

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

1. PADI：PPPoE发现阶段的第一步。用户主机以广播的方式发送PADI数报包，请求建立链路。Code域置为0x09，会话ID域必须置为0x0000。

2. PADO：PPPoE发现阶段的第二步。访问集中器（AC）以单播的方式发送一个PADO数据包对主机的请求做出应答。目的地址为主机的MAC地址，Code域置为0x07，会话ID域必须置为0x0000。PADO数据包必须包含一个类型为AC-Name的Tag（包含了访问集中器的名字）。

3. PADR：PPPoE发现阶段的第三步。因为PADI数据包是广播的，所以主机可能收到不止一个的PADO报文。主机在收到报文后，会根据AC-Name或者PADO所提供的服务来选择一个AC，然后主机向选中的AC单播一个PADR数据包。目的地址域为AC的MAC地址，Code域置为0x19，会话ID域必须置为0x0000。PADR报文必须且只能包含一个Tag_Type为Service-Name的Tag，表明主机请求的服务。

4. PADS：PPPoE发现阶段最后一步。当AC在收到PADR报文时，就准备开始一个PPP的会话了。它为PPPoE会话创建一个唯一的会话ID并用单播一个PADS数据包来给主机做出响应。目的地址域为主机的MAC地址，Code域置为0x65，会话ID必须设置为所创建好的会话ID。

注意：

1. Host-Uniq

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

Tag_Type = 0103 (表示为Host-Uniq)

Tag_Length = 8 （8个字节的长度）

Tag_Value = 0500000008000000

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

2. AC-Cookie

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

二、会话阶段（PPP)

PPP会话的建立，需要两端的设备都发送LCP（Link Control Protocol）数据包来配置和测试数据通信链路。

LCP报文可以分为三类：链路配置报文（LCP Configure Request，LCP Configure Reject，LCP Configure Ack和LCP Configure Nak）、链路终止报文和链路维护报文。

1. 协商阶段

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

LCP协商阶段的数据帧由三部分组成：以太网头，PPPoE头和PPP头。PPPoE Session的以太网类型域为0x8864。

PPP信息包括： Code＝01（表示Configure Request,请求同意Option中的内容）

02（表示Configure Ack，完全同意）

03（表示Configure Nak，同意部分Option中的内容，还需要再协商）

04（表示Configure Reject，完全不同意）

06（Terminate Ack，正常下网）

1. 当Config-Request报文的一端能识别发送过来的所有配置参数选项且认可所有配置参数选项数据域的内容时，接收端将会给对端回一个Config-Ack报文并将配置请求报文中的配置参数选项原封不动的放置在Config-Ack报文的数据域内。

2. 当接收Config-Request报文的一端能识别发送端所发送过来的所有配置参数选项，但对部分配置参数选项数据域中的内容不认可时，接收端将会给对端回应一个Config-Nak报文，该报文只携带不认可的配置参数选项，而这些配置参数选项的数据内容为本端希望的值。

当接收端接收到Config-Nak报文后，会重新新发送Config-Request报文。这次的报文和上一次报文的区别在于那些被对端不认可的配置参数选项的内容被替换成Config-Nak报文里面相应的内容。

3. 当接收Config-Request报文的一端不能识别所有发送端发送过来的配置参数选项时，此时接收端将会向对端回一个Config-Reject报文，该报文中的数据域只携带那些不能识别的配置参数选项。当对端接收到Config-Reject报文后，会再次发送Config-Request报文，只是将不被识别的那些配置参数选项给删除了。
2. 认证阶段

会话双方通过LCP协商好的认证方法进行认证，如果认证通过了，才可以进行下面的网络层的协商。认证过程在链路协商结束后就进

行。但此时可能链路质量的协商还在进行。所以会延缓认证过程。

认证阶段包括：Challenge Packet Identifier ,Response Packet Identifier. Success Packet Identifier和Failure Packet Identifier

认证报文包括：以太网头，PPPOE头，PPP头和CHAP头（采用的是Chap认证）。

以太网头和PPPOE头跟LCP中的相似。PPP头中，Protocol＝0xc223（Challenge Handshake Authentication）

认证通过要经过三个步骤：首先AC发送Challenge Packet Identifier，然后客户端发送 Response Packet Identifier，最后AC发送Success Packet Identifier。

认证失败要经过三个步骤：首先AC发送Challenge Packet Identifier，然后客户端发送两次 Response Packet Identifier，最后AC发送 Failure Packet Identifier。

3.IPCP协商阶段

用户和接入设备对IP服务阶段的一些要求进行多次协商，以决定双方都能够接收的约定。如：IP业务阶段使用的IP压缩协议等。双方的协议是通过报文中包含的Option项进行协商的，每一个Option都是一个需要协商的问题。最后双方都需要对方答复Configure_Ack的同意报文。

IPCP阶段的报文：以太网头，PPPoE头，PPP。以太网头和PPPOE头跟LCP阶段相同。

PPP中存放的是多个Option。Option格式与LCP的TLV相同。

Configure_Request：要求协商的Option

Configure_Nak：表示对收到的Option都可识别，但是一些不能够接收。

Configure_Ack：表示对收到的都能够接收。

Configure_Reject：收到的Option不能够接收。

达成一致后，进入数据包的真正传输阶段，即IP阶段。用户和AC之间通信都开始使用对方的IP地址而不是MAC地址。