?? rfc1661.html
字號(hào):
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"><HTML><HEAD><TITLE>RFC 1661 (rfc1661) - The Point-to-Point Protocol (PPP)</TITLE><META name="description" content="RFC 1661 - The Point-to-Point Protocol (PPP)"><META name="obsoletes" content="RFC1548"><META name="also" content="STD0051"><script language="JavaScript1.2">function erfc(s){document.write("<A href=\"/rfccomment.php?rfcnum="+s+"\" target=\"_blank\" onclick=\"window.open('/rfccomment.php?rfcnum="+s+"','Popup','toolbar=no,location=no,status=no,menubar=no,scrollbars=yes,resizable=yes,width=680,height=530,left=30,top=43'); return false;\")>Comment on RFC "+s+"</A>\n");}//--></script></HEAD><BODY BGCOLOR="#ffffff" TEXT="#000000"><P ALIGN=CENTER><IMG SRC="/images/library.jpg" HEIGHT=62 WIDTH=150 BORDER="0" ALIGN="MIDDLE" ALT=""></P><H1 ALIGN=CENTER>RFC 1661 (RFC1661)</H1><P ALIGN=CENTER>Internet RFC/STD/FYI/BCP Archives</P><DIV ALIGN=CENTER>[ <a href="/rfcs/">RFC Index</a> | <A HREF="/rfcs/rfcsearch.html">RFC Search</A> | <a href="/faqs/">Usenet FAQs</a> | <a href="/contrib/">Web FAQs</a> | <a href="/docs/">Documents</a> | <a href="http://www.city-data.com/">Cities</a> ]<P><STRONG>Alternate Formats:</STRONG> <A HREF="/ftp/rfc/rfc1661.txt">rfc1661.txt</A> | <A HREF="/ftp/rfc/pdf/rfc1661.txt.pdf">rfc1661.txt.pdf</A></DIV><p align=center><script language="JavaScript"><!--erfc("1661");// --></script></p><h3 align=center>RFC 1661 - The Point-to-Point Protocol (PPP)</h3><HR SIZE=2 NOSHADE><PRE>Network Working Group W. Simpson, EditorRequest for Comments: 1661 DaydreamerSTD: 51 July 1994Obsoletes: 1548Category: Standards Track The Point-to-Point Protocol (PPP)Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.Abstract The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP is comprised of three main components: 1. A method for encapsulating multi-protocol datagrams. 2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. 3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. The PPP Link Control Protocol (LCP) is described in terms of this mechanism.Table of Contents 1. Introduction .......................................... 1 1.1 Specification of Requirements ................... 2 1.2 Terminology ..................................... 3 2. PPP Encapsulation ..................................... 4 3. PPP Link Operation .................................... 6 3.1 Overview ........................................ 6 3.2 Phase Diagram ................................... 6 3.3 Link Dead (physical-layer not ready) ............ 7 3.4 Link Establishment Phase ........................ 7 3.5 Authentication Phase ............................ 8 3.6 Network-Layer Protocol Phase .................... 8 3.7 Link Termination Phase .......................... 9 4. The Option Negotiation Automaton ...................... 11 4.1 State Transition Table .......................... 12 4.2 States .......................................... 14 4.3 Events .......................................... 16 4.4 Actions ......................................... 21 4.5 Loop Avoidance .................................. 23 4.6 Counters and Timers ............................. 24 5. LCP Packet Formats .................................... 26 5.1 Configure-Request ............................... 28 5.2 Configure-Ack ................................... 29 5.3 Configure-Nak ................................... 30 5.4 Configure-Reject ................................ 31 5.5 Terminate-Request and Terminate-Ack ............. 33 5.6 Code-Reject ..................................... 34 5.7 Protocol-Reject ................................. 35 5.8 Echo-Request and Echo-Reply ..................... 36 5.9 Discard-Request ................................. 37 6. LCP Configuration Options ............................. 39 6.1 Maximum-Receive-Unit (MRU) ...................... 41 6.2 Authentication-Protocol ......................... 42 6.3 Quality-Protocol ................................ 43 6.4 Magic-Number .................................... 45 6.5 Protocol-Field-Compression (PFC) ................ 48 6.6 Address-and-Control-Field-Compression (ACFC) SECURITY CONSIDERATIONS ...................................... 51 REFERENCES ................................................... 51 ACKNOWLEDGEMENTS ............................................. 51 CHAIR'S ADDRESS .............................................. 52 EDITOR'S ADDRESS ............................................. 521. Introduction The Point-to-Point Protocol is designed for simple links which transport packets between two peers. These links provide full-duplex simultaneous bi-directional operation, and are assumed to deliver packets in order. It is intended that PPP provide a common solution for easy connection of a wide variety of hosts, bridges and routers [1]. Encapsulation The PPP encapsulation provides for multiplexing of different network-layer protocols simultaneously over the same link. The PPP encapsulation has been carefully designed to retain compatibility with most commonly used supporting hardware. Only 8 additional octets are necessary to form the encapsulation when used within the default HDLC-like framing. In environments where bandwidth is at a premium, the encapsulation and framing may be shortened to 2 or 4 octets. To support high speed implementations, the default encapsulation uses only simple fields, only one of which needs to be examined for demultiplexing. The default header and information fields fall on 32-bit boundaries, and the trailer may be padded to an arbitrary boundary. Link Control Protocol In order to be sufficiently versatile to be portable to a wide variety of environments, PPP provides a Link Control Protocol (LCP). The LCP is used to automatically agree upon the encapsulation format options, handle varying limits on sizes of packets, detect a looped-back link and other common misconfiguration errors, and terminate the link. Other optional facilities provided are authentication of the identity of its peer on the link, and determination when a link is functioning properly and when it is failing. Network Control Protocols Point-to-Point links tend to exacerbate many problems with the current family of network protocols. For instance, assignment and management of IP addresses, which is a problem even in LAN environments, is especially difficult over circuit-switched point-to-point links (such as dial-up modem servers). These problems are handled by a family of Network Control Protocols (NCPs), which each manage the specific needs required by their respective network-layer protocols. These NCPs are defined in companion documents. Configuration It is intended that PPP links be easy to configure. By design, the standard defaults handle all common configurations. The implementor can specify improvements to the default configuration, which are automatically communicated to the peer without operator intervention. Finally, the operator may explicitly configure options for the link which enable the link to operate in environments where it would otherwise be impossible. This self-configuration is implemented through an extensible option negotiation mechanism, wherein each end of the link describes to the other its capabilities and requirements. Although the option negotiation mechanism described in this document is specified in terms of the Link Control Protocol (LCP), the same facilities are designed to be used by other control protocols, especially the family of NCPs.1.1. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications must be understood and carefully weighed before choosing a different course. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option.1.2. Terminology This document frequently uses the following terms: datagram The unit of transmission in the network layer (such as IP). A datagram may be encapsulated in one or more packets passed to the data link layer. frame The unit of transmission at the data link layer. A frame may include a header and/or a trailer, along with some number of units of data. packet The basic unit of encapsulation, which is passed across the interface between the network layer and the data link layer. A packet is usually mapped to a frame; the exceptions are when data link layer fragmentation is being performed, or when multiple packets are incorporated into a single frame. peer The other end of the point-to-point link. silently discard The implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter.2. PPP Encapsulation The PPP encapsulation is used to disambiguate multiprotocol datagrams. This encapsulation requires framing to indicate the beginning and end of the encapsulation. Methods of providing framing are specified in companion documents. A summary of the PPP encapsulation is shown below. The fields are transmitted from left to right. +----------+-------------+---------+ | Protocol | Information | Padding | | 8/16 bits| * | * | +----------+-------------+---------+ Protocol Field The Protocol field is one or two octets, and its value identifies the datagram encapsulated in the Information field of the packet. The field is transmitted and received most significant octet first. The structure of this field is consistent with the ISO 3309 extension mechanism for address fields. All Protocols MUST be odd; the least significant bit of the least significant octet MUST equal "1". Also, all Protocols MUST be assigned such that the least significant bit of the most significant octet equals "0". Frames received which don't comply with these rules MUST be treated as having an unrecognized Protocol. Protocol field values in the "0***" to "3***" range identify the network-layer protocol of specific packets, and values in the "8***" to "b***" range identify packets belonging to the associated Network Control Protocols (NCPs), if any. Protocol field values in the "4***" to "7***" range are used for protocols with low volume traffic which have no associated NCP. Protocol field values in the "c***" to "f***" range identify packets as link-layer Control Protocols (such as LCP). Up-to-date values of the Protocol field are specified in the most recent "Assigned Numbers" RFC [2]. This specification reserves the following values: Value (in hex) Protocol Name 0001 Padding Protocol 0003 to 001f reserved (transparency inefficient) 007d reserved (Control Escape) 00cf reserved (PPP NLPID) 00ff reserved (compression inefficient) 8001 to 801f unused 807d unused 80cf unused 80ff unused c021 Link Control Protocol c023 Password Authentication Protocol c025 Link Quality Report c223 Challenge Handshake Authentication Protocol Developers of new protocols MUST obtain a number from the Internet Assigned Numbers Authority (IANA), at <A HREF="mailto:IANA@isi.edu">IANA@isi.edu</A>. Information Field The Information field is zero or more octets. The Information field contains the datagram for the protocol specified in the Protocol field. The maximum length for the Information field, including Padding,?? 快捷鍵說(shuō)明
復(fù)制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號(hào)
Ctrl + =
減小字號(hào)
Ctrl + -