📄 c-dll4.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><html><head><link rel="STYLESHEET" type="text/css" href="wrs.css"><title> Data Link Layer Network Components </title></head><body bgcolor="FFFFFF"><p class="navbar" align="right"><a href="index.html"><img border="0" alt="[Contents]" src="icons/contents.gif"></a><a href="c-dll.html"><img border="0" alt="[Index]" src="icons/index.gif"></a><a href="c-dll.html"><img border="0" alt="[Top]" src="icons/top.gif"></a><a href="c-dll3.html"><img border="0" alt="[Prev]" src="icons/prev.gif"></a><a href="c-dll5.html"><img border="0" alt="[Next]" src="icons/next.gif"></a></p><font face="Helvetica, sans-serif" class="sans"><h3 class="H2"><i><a name="84371">3.4 PPP, the Point-to-Point Protocol for Serial Line IP</a></i></h3></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="93952"> </a>The VxWorks implementation of the PPP (Point-to-Point Protocol) is comprised of several different protocols that work together with the PPP network interface driver. Although PPP can, in theory, support a variety of protocols, the VxWorks implementation supports only the TCP/IP stack. The VxWorks PPP implementation is comprised of three main components:</p></dl><dl class="margin"><p class="listspace"><ul class="Bullet" type="disc"><li><a name="93953"> </a>A method for encapsulating multi-protocol datagrams.</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="84376"> </a>A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection.</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="84378"> </a>A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.</li></ul></p></dl><dl class="margin"><dd><p class="Body"><a name="93965"> </a>PPP is one method by which VxWorks can communicate with other operating systems over a serial line connection. PPP supports Internet Protocol (IP) layer networking software over point-to-point configurations, such as long-distance telephone lines or RS-232 serial connections between machines. If either end of a PPP connection has other network interfaces (such as Ethernet) and is able to forward packets to other machines, a PPP connection can serve as a gateway between networks.</p><dd><p class="Body"><a name="93966"> </a>The basic functionality provided by PPP is similar to that of the Serial Line Internet Protocol (SLIP), with the advantage that PPP is extensible and offers various configurable options.</p><dd><p class="Body"><a name="84381"> </a>PPP provides a standard method for transporting multi-protocol datagrams over point-to-point links. It is designed for simple links which transport packets between two peers. These links provide full-duplex, simultaneous operation and are assumed to deliver packets in the order in which they are sent. It is intended that PPP provide a common solution for easy connectivity among a variety of hosts, bridges, and routers. </p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="84382">3.4.1 Reference Material on PPP</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84384"> </a>The following is a list of relevant Requests for Comments (RFCs) associated with the VxWorks PPP implementation:</p><dl class="margin"><dd><div class="Indent"><a name="84385"> </a><i class="title">RFC 1332</i>: The PPP Internet Protocol Control Protocol (IPCP)</div><br><dd><div class="Indent"><a name="84387"> </a><i class="title">RFC 1334</i>: PPP Authentication Protocols</div><br><dd><div class="Indent"><a name="84389"> </a><i class="textVariable">RFC 1548</i>: The Point-to-Point Protocol (PPP)</div><br></dl><dd><p class="Body"><a name="84392"> </a>The USENET news group, <b>comp.protocols.ppp</b>, is dedicated to the discussion of PPP-related issues. Information presented in this forum is often of a general nature (such as equipment, setup, or troubleshooting), but technical details concerning specific PPP implementations are discussed as well. </p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="84394">3.4.2 PPP Features</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84395"> </a>PPP supports the following features:</p></dl><dl class="margin"><p class="listspace"><ul class="Bullet" type="disc"><li><a name="84397"> </a><font face="Helvetica, sans-serif" size="-1" class="sans"><b class="hb">PPP client and server connection support</b></font> (either <i class="i">active</i> or <i class="i">passive</i> mode). In active mode (default), the PPP software attempts to initiate a PPP link with the peer. In passive mode, the PPP software waits for a peer to try to open a link.</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="84399"> </a><font face="Helvetica, sans-serif" size="-1" class="sans"><b class="hb">Multiple unit support</b></font>. Up to 16 PPP interfaces can be active at any one time.</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="84401"> </a><font face="Helvetica, sans-serif" size="-1" class="sans"><b class="hb">Asynchronous character mapping</b></font>. Users can specify control characters that should be escaped by the peer upon transmission to avoid misinterpretation by the serial driver library or by lower-level modem software.</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="84403"> </a><font face="Helvetica, sans-serif" size="-1" class="sans"><b class="hb">Van Jacobsen (VJ) compression</b></font><i class="i">. </i>This feature reduces the regular 40-byte TCP/IP header to 3 or 8 bytes, thereby saving valuable link bandwidth.</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="84405"> </a><font face="Helvetica, sans-serif" size="-1" class="sans"><b class="hb">Address, control, and protocol field compression</b></font><i class="i">. </i>These types of compression allow the PPP network interface driver to reduce the transmission of extraneous PPP header information, thereby saving valuable link bandwidth.</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="84407"> </a><font face="Helvetica, sans-serif" size="-1" class="sans"><b class="hb">Link state and link statistics querying</b></font>. Internal PPP counters and protocol state information may be obtained through query routines. This enables applications to monitor and manage the PPP link.</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="84409"> </a><font face="Helvetica, sans-serif" size="-1" class="sans"><b class="hb">IP address negotiation</b></font>. Using IP address negotiation, one peer may assign the other peer an IP address once the PPP link is established.</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="84411"> </a><font face="Helvetica, sans-serif" size="-1" class="sans"><b class="hb">Echo request and reply</b></font><i class="i">. </i>One peer may request that the other peer respond to link-layer echoes. This allows for an automatic monitoring of the link's physical status.</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="84413"> </a><font face="Helvetica, sans-serif" size="-1" class="sans"><b class="hb">Connect and disconnect hooks</b></font>. Use of connect and disconnect hooks allows applications to implement routines supporting modem control, dialing software, connection scripting, etc.</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="84415"> </a><font face="Helvetica, sans-serif" size="-1" class="sans"><b class="hb">Challenge-Handshake Authentication Protocol (CHAP) and Password Authentication Protocol (PAP)</b></font>. These authentication protocols ensure that the remote peer is authorized to establish a PPP link and that the correct IP address is used.</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="84419"> </a><font face="Helvetica, sans-serif" size="-1" class="sans"><b class="hb">Proxy ARP routing</b></font>. Use of this feature allows hosts on the proxy-server peer's connected network to access the proxy-client peer without manually adding routing entries.</li></ul></p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="84420">3.4.3 The Point-to-Point Protocol Compared to SLIP</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84422"> </a>For many years, transferring Internet Protocol (IP) packets over serial lines was handled almost exclusively by the Serial Line Internet Protocol (SLIP). SLIP is a simple link-layer driver that is installed between IP stack code and a serial driver. While SLIP uses less object code than PPP and processes packets more efficiently (using compressed headers in CSLIP), it can carry only IP packets and it is not extensible. Furthermore, SLIP has several different protocol implementations that do not always communicate smoothly with each other. Nevertheless, its general ease of use and large installed base has made it the <i class="i">de facto</i> standard for using IP over point-to-point serial lines.</p><dd><p class="Body"><a name="84423"> </a>The Point-to-Point Protocol (PPP) was developed to address the shortcomings of SLIP. Unlike SLIP, PPP is being defined and tracked by the Internet Engineering Task Force (IETF), and the protocol specifications have been published in multiple Request For Comments (RFC) documents. Although SLIP is still an attractive choice for systems that only require basic IP-packet transfers, the advantages of PPP are prompting the rapid growth of its installed base.</p><dd><p class="Body"><a name="84424"> </a>PPP supports several features that make it more suitable than SLIP for certain applications:</p></dl><dl class="margin"><p class="listspace"><ul class="Bullet" type="disc"><li><a name="84425"> </a><font face="Helvetica, sans-serif" size="-1" class="sans"><b class="hb">Multi-Protocol Support</b></font>. PPP packet framing includes a protocol field in the header. This allows for the transfer of packets among different network-layer protocols over a link. At present, the only protocols supported by this PPP implementation are IP and the basic PPP protocols (LCP, IPCP, PAP, and CHAP).</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="84426"> </a><font face="Helvetica, sans-serif" size="-1" class="sans"><b class="hb">Extensibility</b></font>. The protocol field in the frame header makes PPP able to accommodate new protocols (both public and proprietary). The Internet Assigned Numbers Authority (IANA) tracks the allocation of protocol field values. </li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="84427"> </a><font face="Helvetica, sans-serif" size="-1" class="sans"><b class="hb">Error Detection</b></font>. PPP framing also includes a Frame Check Sequence (FCS). This field automatically ensures the data integrity of every packet received by the PPP network interface driver. If an error is detected, the received packet is dropped and an input error is recorded.</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="84428"> </a><font face="Helvetica, sans-serif" size="-1" class="sans"><b class="hb">Link Management</b></font>. The entire structure of PPP is based around the concept of a point-to-point <i class="i">link</i> which is established between <i class="term">peers</i> (the local and remote systems on either end of the serial connection). The link has several phases and states associated with its life and is managed by its own separate protocol, the Link Control Protocol (LCP). This concept of a link creates an environment that can support features like option negotiation, link-layer user authentication, link quality management, and loopback detection.</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="84429"> </a><font face="Helvetica, sans-serif" size="-1" class="sans"><b class="hb">Option Negotiation</b></font>. PPP allows for the dynamic negotiation of options between peers. To some extent, this allows one end of the link to configure the peer. This is especially useful in heterogeneous environments where a PPP server may need to assign certain properties to the peer, such as the Maximum Receive Unit (MRU).</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="84430"> </a><font face="Helvetica, sans-serif" size="-1" class="sans"><b class="hb">Authentication</b></font>. PPP supports link-layer authentication through two widely used authentication protocols: PAP and CHAP. Both of these protocols check that the peer is authorized to establish a link with the local host by sending and/or receiving password information.</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="84431"> </a><font face="Helvetica, sans-serif" size="-1" class="sans"><b class="hb">IP Address Negotiation</b></font>. Built into the PPP control protocol for IP is the ability to assign an IP address to a peer. This feature allows one peer to act as a PPP server and assign addresses as clients dial in. The IP address can be re-used when the PPP link is terminated. </li></ul></p></dl><dl class="margin"><dd><p class="Body"><a name="84432"> </a>While many applications do not require any of the features above, they may need to interact with other systems that are using PPP and not SLIP. These two protocols can <i class="i">not</i> communicate with each other; this is perhaps the most compelling reason for using PPP.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="84434">3.4.4 An Overview of PPP</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84435"> </a>PPP provides for the encapsulation of data in frames. It also supports the following protocols: </p></dl><dl class="margin"><ul class="BulletSingle" type="disc"><li><a name="84436"> </a>Link Control Protocol (LCP)</li></ul><ul class="BulletSingle" type="disc"><li><a name="84437"> </a>Internet Protocol Control Protocol (IPCP)</li></ul><ul class="BulletSingle" type="disc"><li><a name="84438"> </a>Password Authentication Protocol (PAP)</li></ul><ul class="BulletSingle" type="disc"><li><a name="84439"> </a>Challenge-Handshake Authentication Protocol (CHAP)</li></ul></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="84441">Encapsulation</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84442"> </a>PPP encapsulation provides for simultaneous multiplexing of different network-layer protocols over the same link. The PPP encapsulation has been carefully designed to retain compatibility with most commonly used supporting hardware. The frame format of a standard PPP frame structure is shown in <a href="c-dll4.html#84449">Figure 3-1</a>.<div class="frame"><h4 class="EntityTitle"><a name="84449"><font face="Helvetica, sans-serif" size="-1" class="sans">Figure 3-1: Format of Standard PPP Frame Structure</font></a></h4><dl class="margin"><div class="Anchor"><a name="84487"> </a><img class="figure" border="0" src="images/c-dll0.gif"></div></dl></div></p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="84489">Link Control Protocol (LCP)</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84491"> </a>In order to promote versatility and be portable to a wide variety of environments, PPP provides a Link Control Protocol (LCP). LCP is used when establishing links and negotiating a variety of configuration options. It is also used to create automatic agreement on encapsulation format options, to handle variable size limits placed on packets, to detect looped-back links and other common configuration errors, and to terminate links. </p><dd><p class="Body"><a name="84493"> </a>Other optional facilities provided by LCP include: authentication of the peer on the link by using authentication protocols such as PAP or CHAP, and determination when a link is functioning properly and when it is failing. After the link is established, PPP also allows an optional authentication. For more information, see RFC 1548.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="84495">Internet Protocol Control Protocol (IPCP)</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84497"> </a>The IP Control Protocol (IPCP) is the Network Control Protocol (NCP) for IP. IPCP is responsible for configuring, enabling, and disabling the IP protocol modules on both ends of the point-to-point link. It uses the same packet exchange mechanism as LCP. IPCP packets are not exchanged until PPP has established a link. IPCP is also responsible for IP address negotiation between peers. For more information, see RFC 1332.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="84499">Password Authentication Protocol (PAP)</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84501"> </a>The Password Authentication Protocol (PAP) provides a simple method by which the peer establishes its identity using a two-way handshake. This is done only upon the initial link creation. Once a link is established, an ID/password pair is sent repeatedly by the peer to the authenticator until authentication is acknowledged or the connection is terminated. </p><dd><p class="Body"><a name="84502"> </a>PAP is not a robust authentication protocol. Passwords are sent over the circuit "in the clear," without protection from playback or repeated trial-and-error attacks. The peer is in control of the frequency and timing of the attempts. This authentication method is most appropriately used when a plain-text password must be available to simulate a login at a remote host. For information about using PAP, see <a href="c-dll4.html#85309"><i class="title">Using PAP</i></a>, or refer to RFC 1334. </p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="97721">Challenge-Handshake Authentication Protocol (CHAP)</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="97723"> </a>Challenge-Handshake Authentication Protocol (CHAP) is a more robust authentication protocol offering better security than PAP. CHAP periodically verifies the identity of a peer using a three-way handshake. This is done after an initial link is established, and can be repeated later at any time. </p><dd><p class="Body"><a name="84512"> </a>After a link is established, the authenticator sends a "challenge" message to the peer. The peer responds with a value calculated by a one-way hash function. The authenticator checks the response against its own calculation of the expected hash value. If the values match, the authentication is acknowledged; otherwise the connection is terminated. </p><dd><p class="Body"><a name="84513"> </a>CHAP provides protection against playback attack by issuing ever-changing challenges at specified time intervals. The use of repeated challenges is intended to limit the time of exposure to any single attack. The authenticator is in control of the frequency and timing of the challenges. </p><dd><p class="Body"><a name="84514"> </a>CHAP authentication for any particular link relies on the use of a "secret" known only to the authenticator and the peer. The secret is not sent over the link; therefore the server and its peer must both have access to it. In Tornado, this is achieved using various methods explained in <a href="c-dll4.html#85338"><i class="title">Using CHAP</i></a>. For further technical details, refer to RFC 1334.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="84520">3.4.5 PPP Configuration</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84522"> </a>Configuring your environment for PPP requires both host and target software installation and configuration. See your host's operating system manual for information on installing and configuring PPP on your host.<sup><a href="#foot"><b class="FootnoteMarker">1</b></a></sup></p><dd><p class="Body"><a name="84529"> </a>To include the default PPP configuration, configure VxWorks with PPP support. The relevant configuration macro is <b class="symbol_UC">INCLUDE_PPP</b>.</p></dl></dl><dl class="margin"><dd><p class="table" callout><table border="0" cellpadding="0" cellspacing="0"><tr valign="top"><td valign="top" width="40"><br><img border="0" alt="*" src="icons/caution.gif"></td><td><hr><div class="CalloutCell"><a name="93547"><b class="symbol_UC"><font face="Helvetica, sans-serif" size="-1" class="sans">CAUTION: </font></b></a>A VxWorks image that includes PPP sometimes fails to load. This failure is due to the static maximum size of the VxWorks image allowed by the loader. This problem can be fixed by either reducing the size of the VxWorks image (by removing unneeded options), or by burning new boot ROMs. If you receive a warning from <b class="symbol_lc">vxsize</b> when building VxWorks, or if the size of your image becomes greater than that supported by the current setting of <b class="symbol_UC">RAM_HIGH_ADRS</b>, see <i class="title">Creating Bootable Applications</i> in the <i class="title">Tornado User's Guide: Cross-Development</i> for information on how to resolve the problem.</div></td></tr><tr valign="top"><td></td><td><hr></td></tr>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -