pppoe!

sprintf

哪位大侠介绍一下pppoe协议啊！！！！！！

liuiang

1. PPP over Ethernet协议
　1998年后期问世的以太网上点对点协议（PPP over Ethernet）技术是由Redback 网络公司、客户端软软 件开发商RouterWare公司以及Worldcom子公司UUNET Technologies公司在IETF RFC制的基础上联合开发的。通过把最经济的局域网技术 以太网和点对点协议的可扩展性及管理控制功能结合在一起，网络服务提供商和电信运营商便可利用可靠和熟悉的技术来加速部署高速互联网业务。它使服务提供商 在通过数字用户线、电缆调制解调器或无线连接等方式，提供支持多用户的宽带接入服务时更加简便易行。同时该技术亦简化了最终用户在动态地选择这些服务时的 操作。
　2. PPP over Ethernet基本帧格式
　建立一个以太网上点对点协议会话包括两个阶段：1. 发现（Discovery）阶段。在Discovery过程中用户主机以广播方式寻找可以连接的所有的接入集线器，并获得其以太网MAC地址。然后选择需 要连接的主机并确定所要建立的PPP会话识别标号。2. PPP会话阶段。用户主机与接入集线器根据在发现阶段所协商的PPP会话连接参数进行PPP会话。因此对应于这两种过程，以太网上点对点协议帧格式（如图 2）也包括两种类型：发现阶段的以太网帧中的类型字段为0x8863；PPP会话阶段的以太网帧中的类型字段为0x8864，它们均已得到IEEE的认 可。PPPoE包中的版本(VER) 字段和类型（TYPE）字段长度均为4比特，在当前版本PPPoE建议中这两个字段值都固定为0x1。代码（CODE）字段长度为8比特，根据两阶段中各 种数据包的不同功能而值不同。在PPP会话阶段CODE字段为0x00，发现阶段中的各种数据包格式将在下面详细介绍发现阶段时给出。版本标识号码 （SESSION_ID）字段长度为16比特，在一个给定的PPP会话过程中它是固定不变的。值0xffffff为保留值。长度（LENGTH）字段为 16比特长，指示PPPoE净荷长度。发现阶段PPPoE载荷可以为空或由多个标记（TAG）组成，每个标记都是TLV（类型-长度-值）的结构；PPP 会话阶段PPPoE载荷为标准的点对点协议包。
　3. 发现（Discovery）阶段的详细介绍
　一个典型的发现 （Discovery）阶段共包括4个步骤：1. 主机发出PPPoE有效发现启动（PADI）包。以太网目的地址为广播地址0xffffffffffff，CODE字段为0x09，SESSION_ID 为0x0000。PADI包必须至少包含一个服务名称类型的标签（标签类型字段为0x0101），向接入集线器提出所要求提供的服务。2. 接入集线器收到在服务范围内的PADI包后，发送PPPoE有效发现提供（PADO）包以响应请求。其CODE字段为0x07 ，SESSION_ID仍为0x0000。PADO包必须包含一个接入集线器名称类型的标签（标签类型字段为0x0102）以及一个或多个服务名称类型标 签，表明可向主机提供的服务种类。3. 主机在可能收到的多个PADO包中选择一个合适的，然后向所选择的接入集线器发送PPPoE有效发现请求（PADR）包。其CODE字段为0x19 ，SESSION_ID仍为0x0000。PADR包必须包一个服务名称类型标签，确定向接入集线器请求的服务种类。4. 接入集线器收到PADR包后准备开始PPP会话，它发送一个PPPoE有效发现会话确认（PADS）包。其CODE字段为0x65 ，SESSION_ID为接入集线器所产生的一个唯一的PPPoE会话标识号码。PADS包也必须包含一个接入集线器名称类型的标签确认向主机提供的服 务。当主机收到PADS包确认后，双方就进入PPP会话阶段。
　还有一种PPPoE有效发现终止（PADT）包，在一个PPP会话建立后它随时可由主机或接入集线器中任何一方发送，指示PPP会话已终止。PADT包不需要任何标签，其CODE字段为0xa7 ，SESSION_ID为需要终止的PPP会话的会话标识号码。
　4. 以太网上点对点协议的优点
　安裝与操作方式类似于以往的拨号网络模式，方便用戶使用。　
　用户处的xDSL调制解调器无须任何配置。　
　允许多个用户共享一个高速数据接入链路。适应小型企业和远程办公的要求。　
　终端用户可同时接入多个ISP，这种动态服务选择的功能可以使ISP容易创建和提供新的业务。　
　兼容现有所有的xDSL Modem 和DSLAM。　
　可与ISP現有接入结构相融合。

liuiang

版权属于------
PPP over Ethernet 的技术介绍
来源：ChinaITLab
2003-3-6 22:44:00

一声叹息

PPP over Ethernet (PPPoE)
This protocol, described in Informational RFC 2516, is not the result of any IETF work. Instead, it is a protocol designed within the ADSL Forum.
RFC 2516 is very simple. It begins with a four-way DHCP-like handshake where a PPP user finds other PPPoE systems on the local Ethernet by broadcasting a PPPoE Active Discovery Initiation (PADI) packet with Ethertype 8863. The systems that allow access reply with PPPoE Active Discovery Offer (PADO) messages. The user then picks one of the offers and replies to this server with a PPPoE Active Discovery Request (PADR) message. The selected server returns a PPPoE Active Discovery Session-confirmation (PADS) message that gives a unique session ID number for the new PPP user. PPP can then be tunneled using a distinguished Ethertype (8864) and the specified session ID.
In the usual ADSL configuration, the PPPoE server system is an access concentrator reachable through an ADSL modem that acts as an Ethernet bridge. The access concentrator, which may reside at the telephone company central office or at a remote location over ATM links, communicates with the user’s PPP system and establishes the PPPoE tunnel.
Unfortunately, since PPPoE runs directly over Ethernet with no fragmentation facilities and adds additional headers, RFC 2516 fixes the MRU to a maximum of 1492, in violation of RFC 1661. This problem can be corrected by use of MP within a single session, although no known implementation does this. The LCP MRU must be no greater than 1492, but the MRRU may be any convenient larger value.
Worse still, PPPoE essentially has no security at all. The PPPoE Active Discovery Terminate (PADT) message is unauthenticated. Any user on the local link can terminate or disrupt another user’s PPP session by sending forged PADT messages and by sending false PADO messages. Since, unlike L2TP, PPPoE cannot be run over a secure facility such as IPSec, users may also inject arbitrary packets into existing PPP sessions.
It would be hard to justify the use of this protocol. The ADSL devices that use this protocol could just as easily use a combination of L2TP and DHCP or implement PPP and traditional routing or bridging themselves. Several easily implemented combinations of existing standards would solve the same problems as PPPoE without requiring the invention of a new protocol.